Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #100966 > unrolled thread

Debian package manager privilege escalation attack

Back to article view | Back to linux.debian.devel

Contents

  Debian package manager privilege escalation attack Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2021-08-12 05:40 +0200
    Re: Debian package manager privilege escalation attack Brian Thompson <brian@hashvault.io> - 2021-08-12 06:00 +0200
      Re: Debian package manager privilege escalation attack Andrey Rahmatullin <wrar@debian.org> - 2021-08-12 07:50 +0200
        Re: Debian package manager privilege escalation attack Brian Thompson <brian@hashvault.io> - 2021-08-12 08:20 +0200
          Re: Debian package manager privilege escalation attack Andrey Rahmatullin <wrar@debian.org> - 2021-08-12 08:30 +0200
            Re: Debian package manager privilege escalation attack Paul Tagliamonte <paultag@debian.org> - 2021-08-12 15:00 +0200
    Re: Debian package manager privilege escalation attack Andrey Rahmatullin <wrar@debian.org> - 2021-08-12 07:40 +0200
      Re: Debian package manager privilege escalation attack Vincent Bernat <bernat@debian.org> - 2021-08-12 08:40 +0200
        Re: Debian package manager privilege escalation attack Andrey Rahmatullin <wrar@debian.org> - 2021-08-12 08:40 +0200
          Re: Debian package manager privilege escalation attack Vincent Bernat <bernat@debian.org> - 2021-08-12 09:00 +0200
        Re: Debian package manager privilege escalation attack Ansgar <ansgar@43-1.org> - 2021-08-12 10:40 +0200
          Re: Debian package manager privilege escalation attack Vincent Bernat <bernat@debian.org> - 2021-08-12 11:20 +0200
        Re: Debian package manager privilege escalation attack Philipp Kern <pkern@debian.org> - 2021-08-12 11:20 +0200
        Re: Debian package manager privilege escalation attack David Kalnischkies <david@kalnischkies.de> - 2021-08-12 13:50 +0200
        Re: Debian package manager privilege escalation attack Kyle Edwards <kyle.edwards@kitware.com> - 2021-08-12 14:40 +0200
          Re: Debian package manager privilege escalation attack Andrey Rahmatullin <wrar@debian.org> - 2021-08-12 14:50 +0200
    Re: Debian package manager privilege escalation attack Niels Thykier <niels@thykier.net> - 2021-08-12 07:40 +0200
      Re: Debian package manager privilege escalation attack Andrey Rahmatullin <wrar@debian.org> - 2021-08-12 08:20 +0200
        Re: Debian package manager privilege escalation attack Brian Thompson <brian@hashvault.io> - 2021-08-12 08:30 +0200
          Re: Debian package manager privilege escalation attack Andrey Rahmatullin <wrar@debian.org> - 2021-08-12 08:40 +0200
          Re: Debian package manager privilege escalation attack Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-08-12 12:30 +0200
            Re: Debian package manager privilege escalation attack Philipp Kern <pkern@debian.org> - 2021-08-12 13:50 +0200
              Re: Debian package manager privilege escalation attack Marc Haber <mh+debian-devel@zugschlus.de> - 2021-08-12 18:00 +0200
                Re: Debian package manager privilege escalation attack Philipp Kern <pkern@debian.org> - 2021-08-12 20:10 +0200
                  Re: Debian package manager privilege escalation attack Russ Allbery <rra@debian.org> - 2021-08-12 21:10 +0200
      Re: Debian package manager privilege escalation attack Brian Thompson <brian@hashvault.io> - 2021-08-12 08:20 +0200
        Re: Debian package manager privilege escalation attack Holger Levsen <holger@layer-acht.org> - 2021-08-12 15:20 +0200
          Re: Debian package manager privilege escalation attack Holger Levsen <holger@layer-acht.org> - 2021-08-12 18:10 +0200
          Re: Debian package manager privilege escalation attack Wouter Verhelst <wouter@debian.org> - 2021-08-16 16:50 +0200

Page 1 of 2  [1] 2  Next page →

#100966 — Debian package manager privilege escalation attack

All,

I just ran across this article
https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
the attacks on Debian 11 and they work successfully giving me a root
shell prompt.

Tim

[toc] | [next] | [standalone]

#100967

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, 2021-08-11 at 23:30 -0400, Timothy M Butterworth wrote:
> All,
> 
> I just ran across this article
> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
> the attacks on Debian 11 and they work successfully giving me a root
> shell prompt.
> 
> Tim

Thank you for bringing this to everyone's attention. This are very real
vulnerabilities. NPM has similar issues with stopping malicious packages
from being published to the FTP server. They have made some improvements
after they were aware of the issue, but I haven't heard any new
developments at NPM about how to stop malicious packages from making it
to the server.  Malicious packages can and do make it into the
dependency sets of popular packages. This is a problem. I don't think
that any amount of human effort and attention can prevent malicious
packages from making it to the FTP server. I think that AI would be
better-equipped to handle the critical checks necessary for FTP upload
security to be top-of-the-line. The AI couldn't just be left unchecked,
though, and humans are still needed to monitor, tweak, and make sure the
AI is working and behaving in a responsible manner. As far as behaving
responsibly is concerned, the main issue I foresee is having the AI flag
false positives, and making sure the AI doesn't evolve into something
insidious. I'm not sure if that last point can exist within limited AI,
because I am not an AI expert.

Perhaps a workaround for users right now would be to have a user with
package management sudo access, and not much else. sudo access for
package managers would have to be disallowed at the root and [other]
user levels. I am not even sure that this would even work for all use
cases, and having a manual ad-hoc hotfix is far from ideal. What does
the Debian community think about this?

Also, we should notify our upstream projects, and the Linux community as
a whole, of these vulnerabilities. I believe that to be a moral
obligation.
- -- 
Best regards,

Brian T.
-----BEGIN PGP SIGNATURE-----

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEUm8ATHGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2GfYQuD/47aYb4u7hIZ0n8yAdfzPVHVjvYrOzc
Ke7sSSHktgtsBPxWulXjwggm4/XlYlk06TEmDycr60/Ql1ncPZkZ9L2WaKUWabiy
fZ3wSaN7Sd8fCM2ls4GGr6m66UiqjIYzmlJJrn3WdVQxXvuMULWPyD2yGEYbLydu
QQynSkB18OzTxNtwZYEBV7y7Qe69vZBFa0jfd4kH+zLk6lbmyHLFKn8smnFVQdby
uaFGynpX5faYTeY7ccBUkeveBJMUJcomDlzJZ6XbsmSvaDgX1aPJNkkOzirr8L/5
ilSzydrtifmrvkBcvcesPwEwqHp9xMExYazM7Nz1iLhqafYZHMOiwFnQDF9Tn0cW
mTIEzqz5Jbk9LoBxNMxfcPAd6XHGK/zntUbNhxDGNqgnYHjeWhIKWNj6qAP8yKPp
8W1loXMoKyHeE1A4d7ILJNYczYoGz5V2QlfXgHnWgwzrATDmqs6RHmhHM4BNKYTl
AQAMili65MdULWwkKjtDHube8UVxLyKxkLgfRChSrXq8mkhSb9zRyqthv5z87G84
pKeiy92TXxkV/KZfWyMX8naYnnckcA9x4FS7tLZGqPN6fqRpUNW8XM3snaW99Jbk
GqlCpE1XkQXDhdb3TPd8Uo3FQAVbgce9tmec99HGhWpBrMtay4N7p1xLUQG/mbNM
uyrGcXtiLlGefQ==
=iA8K
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#100971

[Multipart message — attachments visible in raw view] — view raw

On Wed, Aug 11, 2021 at 10:55:44PM -0500, Brian Thompson wrote:
> Thank you for bringing this to everyone's attention. This are very real
> vulnerabilities. 
How are they vulnerabilities?


> NPM has similar issues with stopping malicious packages from being
> published to the FTP server.
That's not what is the article about.

> Malicious packages can and do make it into the dependency sets of
> popular packages. This is a problem. I don't think that any amount of
> human effort and attention can prevent malicious packages from making it
> to the FTP server.
This, again, is not what is the article about. Malicious packages don't
need these "vulnerabilities" as they can put files to your file system
directly.

> Perhaps a workaround for users right now would be to have a user with
> package management sudo access, and not much else. 
Ah, so you haven't read the article.

> Also, we should notify our upstream projects, and the Linux community as
> a whole, of these vulnerabilities. I believe that to be a moral
> obligation.
...

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#100972

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, 2021-08-12 at 10:44 +0500, Andrey Rahmatullin wrote:
> On Wed, Aug 11, 2021 at 10:55:44PM -0500, Brian Thompson wrote:
> > Thank you for bringing this to everyone's attention. This are very
> > real
> > vulnerabilities. 
> How are they vulnerabilities?
> 

They are vulnerabilities because the user is susceptible to this kind of
attack by default. I don't think a lot of users are security-conscious
enough to prevent sudo access for commands like apt and snap.

> > NPM has similar issues with stopping malicious packages from being
> > published to the FTP server.
> That's not what is the article about.

Correct, but NPM served as an anecdote for a point I was trying to make.

> Ah, so you haven't read the article.

No, I read the article.

- -- 
Best regards,

Brian T.
-----BEGIN PGP SIGNATURE-----

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEUvN8THGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2GfZx5D/4i2kVC+zcYFXYad13SPPJjwIRI0pM3
PMKwdb4NIFG8eG3vurWbq/p7cUihXjahpq1xbTkifzfAnE22y9k7Sj85vDR5j2F/
Pfir09qymjLoOdmFCCRuRdraBe8bUuaWolHnHIVdT0Jif3KeRk/I6njn0ZKa0dI3
2yaA9owJPIxRUGki7OMFLwz5WdoTU4t77AHD3JiU9e1QExV/Z2AQi6twGAVqJVVY
JtUan3P/NmWBsBjPxPg+zuAp3/YVPpHBS02mI3A+sHp2qzQDUQ3S9lpuEx/QuxN0
BhLynoqugG8ZQDJvymENFCvr2WYRz1/0heE/YouR9MCLpchdZidSzyTsgvj6BH9d
WipAdocRzqgEWvL+vDbcnG8JKHhzGqpeny08fbMKbl/Nmm7cS781MdWtw7tmk0Nq
Bs3yzneBihgi9duQrvlIncaroBv5FkoGCzNPvL8dKudA8dVLyPWG0rlPSrkRLSfs
zYSVRL/D99G+f8YCz+HmPq1CYEKNxeATZI/l1qrUZq6K5yAlUWHlmEnylZILcUAm
ZnAgIQnpTq/SrH8QLH/03qSZ/lqYi05Rn/Q0WOkv8g+t5I7mytvzKWu9qsZUopWg
YFmVp/4+eyg1SjaCM5PCO6tv2D8AjK8UW0uzwTXT1LF+2DeM7sC8/hgIU49Ebv/T
Q6ZdTfoS3cbL3g==
=W0yz
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#100976

[Multipart message — attachments visible in raw view] — view raw

On Thu, Aug 12, 2021 at 01:17:03AM -0500, Brian Thompson wrote:
> > > Thank you for bringing this to everyone's attention. This are very
> > > real
> > > vulnerabilities. 
> > How are they vulnerabilities?
> They are vulnerabilities because the user is susceptible to this kind of
> attack by default. 
No. Read the article.

> I don't think a lot of users are security-conscious enough to prevent
> sudo access for commands like apt and snap.
The focus of the article is "sudo access *only* to apt". When we talk
about unrestricted sudo access it doesn't even make sense to talk about
privilege escalation because unrestricted sudo is by design a privilege
escalation.

> > Ah, so you haven't read the article.
> No, I read the article.
Yet you are talking about things out of the scope of the article.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#100993

> The focus of the article is "sudo access *only* to apt". When we talk
> about unrestricted sudo access it doesn't even make sense to talk about
> privilege escalation because unrestricted sudo is by design a privilege
> escalation.

Similarly, sudo access *only* to bash enables execution of loads of things.

Hand-installing a user-provided deb could do things like put suid root
binaries on the filesystem, too.


  Paul

--
:wq

[toc] | [prev] | [next] | [standalone]

#100969

[Multipart message — attachments visible in raw view] — view raw

On Wed, Aug 11, 2021 at 11:30:27PM -0400, Timothy M Butterworth wrote:
> I just ran across this article
> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
> the attacks on Debian 11 and they work successfully giving me a root
> shell prompt.
I don't think calling this "privilege escalation" or "attack" is correct.
The premise of the post is "the user should not be a root/admin user but
has been assigned sudo permissions to run the package manager" and one
doesn't really need a long article to prove that it's not secure.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#100977

 ❦ 12 August 2021 10:39 +05, Andrey Rahmatullin:

>> I just ran across this article
>> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
>> the attacks on Debian 11 and they work successfully giving me a root
>> shell prompt.
> I don't think calling this "privilege escalation" or "attack" is correct.
> The premise of the post is "the user should not be a root/admin user but
> has been assigned sudo permissions to run the package manager" and one
> doesn't really need a long article to prove that it's not secure.

I think the article is interesting nonetheless. Some people may think
that granting sudo on apt is OK. In the past, I think "apt install
./something.deb" was not possible.

I give myself password less sudo to "apt update" (without additional
options), "apt upgrade" (same), "apt full-upgrade" (same). I was
thinking this should be safe, but now I need to check if the pager is
properly restricted when displaying NEWS file. A similar
"vulnerability" was fixed in systemd:

 - https://gtfobins.github.io/gtfobins/systemctl/
 - https://github.com/keszybz/systemd/commit/612ebf6c913dd0e4197c44909cb3157f5c51a2f0

Maybe it would be worth to also set LESSSECURE (less is not the default
pager on minimal installs but I think it is the most common, more cannot
be secured this way).
-- 
Use data arrays to avoid repetitive control sequences.
            - The Elements of Programming Style (Kernighan & Plauger)

[toc] | [prev] | [next] | [standalone]

#100979

[Multipart message — attachments visible in raw view] — view raw

On Thu, Aug 12, 2021 at 08:32:14AM +0200, Vincent Bernat wrote:
> >> I just ran across this article
> >> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
> >> the attacks on Debian 11 and they work successfully giving me a root
> >> shell prompt.
> > I don't think calling this "privilege escalation" or "attack" is correct.
> > The premise of the post is "the user should not be a root/admin user but
> > has been assigned sudo permissions to run the package manager" and one
> > doesn't really need a long article to prove that it's not secure.
> 
> I think the article is interesting nonetheless. Some people may think
> that granting sudo on apt is OK. 
Some people may think granting sudo to vim is OK, but we need to educate
in general that some programs can run other programs, and so restricted
sudo is not as restricted as it sounds.

> In the past, I think "apt install ./something.deb" was not possible.
Yup, so "and programs you allowed in the past can gain new features even
if they didn't have them in the past".

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#100980

 ❦ 12 August 2021 11:38 +05, Andrey Rahmatullin:

>> >> I just ran across this article
>> >> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
>> >> the attacks on Debian 11 and they work successfully giving me a root
>> >> shell prompt.
>> > I don't think calling this "privilege escalation" or "attack" is correct.
>> > The premise of the post is "the user should not be a root/admin user but
>> > has been assigned sudo permissions to run the package manager" and one
>> > doesn't really need a long article to prove that it's not secure.
>> 
>> I think the article is interesting nonetheless. Some people may think
>> that granting sudo on apt is OK. 
> Some people may think granting sudo to vim is OK, but we need to educate
> in general that some programs can run other programs, and so restricted
> sudo is not as restricted as it sounds.

That's the point of the article, isn't it? Your example is how I got
fast-forwarded admin when I was at school/uni. So, it's unlikely to
change.
-- 
Habit is habit, and not to be flung out of the window by any man, but coaxed
down-stairs a step at a time.
		-- Mark Twain, "Pudd'nhead Wilson's Calendar

[toc] | [prev] | [next] | [standalone]

#100981

On Thu, 2021-08-12 at 08:32 +0200, Vincent Bernat wrote:
> I give myself password less sudo to "apt update" (without additional
> options), "apt upgrade" (same), "apt full-upgrade" (same). I was
> thinking this should be safe, but now I need to check if the pager is
> properly restricted when displaying NEWS file.

These are not safe to be run under `sudo` without giving the invoking
user full access. As a random example: dpkg's conffile prompt offers to
open a shell.

For the same reason "apt install [package-name]" is unsafe as well even
when you ensure that "[package-name]" only contains characters from the
set [a-z0-9A-Z-] and does not start with a "-".

As another example, being able to answer debconf prompts from certain
packages is likely also root-equivalent.

If you want unprivileged users to manage (install, remove, update)
packages, then I believe PackageKit[1] tries to offer this.

Ansgar

  [1]: https://www.freedesktop.org/software/PackageKit/

[toc] | [prev] | [next] | [standalone]

#100984

 ❦ 12 August 2021 10:31 +02, Ansgar:

>> I give myself password less sudo to "apt update" (without additional
>> options), "apt upgrade" (same), "apt full-upgrade" (same). I was
>> thinking this should be safe, but now I need to check if the pager is
>> properly restricted when displaying NEWS file.
>
> These are not safe to be run under `sudo` without giving the invoking
> user full access. As a random example: dpkg's conffile prompt offers to
> open a shell.

Ack. I'll avoid this from now on.
-- 
Keep it simple to make it faster.
            - The Elements of Programming Style (Kernighan & Plauger)

[toc] | [prev] | [next] | [standalone]

#100983

On 2021-08-12 08:32, Vincent Bernat wrote:
> ❦ 12 August 2021 10:39 +05, Andrey Rahmatullin:
> 
>>> I just ran across this article
>>> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I 
>>> tested
>>> the attacks on Debian 11 and they work successfully giving me a root
>>> shell prompt.
>> I don't think calling this "privilege escalation" or "attack" is 
>> correct.
>> The premise of the post is "the user should not be a root/admin user 
>> but
>> has been assigned sudo permissions to run the package manager" and one
>> doesn't really need a long article to prove that it's not secure.
> 
> I think the article is interesting nonetheless. Some people may think
> that granting sudo on apt is OK. In the past, I think "apt install
> ./something.deb" was not possible.

I think the actual solution here is PackageKit. My understanding is that 
it does not let you do this when you grant the package-install 
permission to users. And it even lets you do flexible policies through 
polkit.

And sure, that still allows users to install packages from any 
configured source which might include packages with vulnerabilities or 
intended privilege escalation. But that feels like a different, more 
general problem.

Kind regards
Philipp Kern

[toc] | [prev] | [next] | [standalone]

#100989

[Multipart message — attachments visible in raw view] — view raw

On Thu, Aug 12, 2021 at 08:32:14AM +0200, Vincent Bernat wrote:
>  ❦ 12 August 2021 10:39 +05, Andrey Rahmatullin:
> >> I just ran across this article
> >> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
> >> the attacks on Debian 11 and they work successfully giving me a root
> >> shell prompt.
> > I don't think calling this "privilege escalation" or "attack" is correct.
> > The premise of the post is "the user should not be a root/admin user but
> > has been assigned sudo permissions to run the package manager" and one
> > doesn't really need a long article to prove that it's not secure.
> 
> I think the article is interesting nonetheless. Some people may think
> that granting sudo on apt is OK. In the past, I think "apt install
> ./something.deb" was not possible.

It wasn't that easy, but if you can feed config options into apt you can
basically do whatever (like setting a sources.list, including your own
local repo including your bad deb). Beside the command line -o and -c
you can also use environment variable APT_CONFIG.

APT (, dpkg, …) just never was designed to be used in a restricted way or
we wouldn't have hundreds upon hundreds of options to do all sorts of
(sometimes) crazy things like using apt for bootstrap…

I would say dd-schroot-cmd is a good example of what you would need,
although I am relatively sure someone truly hostile can find a way if
enough energy is invested (and then there is always the risk of the APT
team adding yet another innocent option derailing the plan like the
ability to install deb files directly used to back in 2014).


> Maybe it would be worth to also set LESSSECURE (less is not the default
> pager on minimal installs but I think it is the most common, more cannot
> be secured this way).

External solvers (--solver/--planner) are run as a (configurable)
different user, currently defaulting to _apt. That is nice, as it isn't
root, but _apt is also used by the download methods, which means it can
have permissions to files it shouldn't have. Ideally, we would need
an extra user for that. Except that different solvers probably shouldn't
be able to access each other, so multiple I guess. Can't really be nobody
(or a temporary) as the solvers might very well have their own config,
cache, I could even envision some asking an online oracle for input
(reproducible, open bugs, …) and firewall rules for nobody are bad ………
sorry, my head hurts, were where I?

Right, pagers. Ideally I would like to not run them as root as well,
but they are a lot more user facing, so if your usual config (hello
lesspipe) disappears it is sad. Fun would be to run the pager as the
user who sudoed initially… :P


We could set this environment variable I guess, but dpkg doesn't set it
either and a quick codesearch in Debian suggests that while the variable
seems sufficiently ancient (console-log changelog mentions it in 2000)
I don't see a whole lot of adoption – and golang-github-sean--pager
surprises me with setting it only if the called pager is named less.
Not sure I like systemds envvar to override an envvar either
(and they of course all use different LESS flags to begin with).

So, before I am rushing off to do whatever I like, could we perhaps
agree on a "sensible-restricted-pager" (I dare not to name it secure…)
sort-of implementation first?


Oh and, btw, there is no point¹ in running 'apt changelog' with root
permissions – it is beside the point here, but I feel obligated to
mention it.


Best regards

David Kalnischkies

¹ well, there is a teeny weeny one: an outdated binary cache is updated
and stored on disk rather then build in memory and discarded afterwards,
but ideally your cache isn't outdated – it usually isn't if you aren't
doing things with envvars, options, …

[toc] | [prev] | [next] | [standalone]

#100991

On 8/12/21 2:32 AM, Vincent Bernat wrote:
>   ❦ 12 August 2021 10:39 +05, Andrey Rahmatullin:
>
>>> I just ran across this article
>>> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
>>> the attacks on Debian 11 and they work successfully giving me a root
>>> shell prompt.
>> I don't think calling this "privilege escalation" or "attack" is correct.
>> The premise of the post is "the user should not be a root/admin user but
>> has been assigned sudo permissions to run the package manager" and one
>> doesn't really need a long article to prove that it's not secure.
> I think the article is interesting nonetheless. Some people may think
> that granting sudo on apt is OK. In the past, I think "apt install
> ./something.deb" was not possible.

Random thought: could it be possible to restrict non-sudo users to 
installing packages from repos that are signed by a GPG key that is 
already trusted by the system (the Debian archive key)? That way this 
attack could not be carried out. Then add a Unix group that allows apt 
installation from trusted repos, make apt setuid so it can do the 
privileged operations, and have it check that the user is root or part 
of the non-privileged group.

Just my $0.02.

Kyle

[toc] | [prev] | [next] | [standalone]

#100992

[Multipart message — attachments visible in raw view] — view raw

On Thu, Aug 12, 2021 at 08:35:42AM -0400, Kyle Edwards wrote:
> > > > I just ran across this article
> > > > https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
> > > > the attacks on Debian 11 and they work successfully giving me a root
> > > > shell prompt.
> > > I don't think calling this "privilege escalation" or "attack" is correct.
> > > The premise of the post is "the user should not be a root/admin user but
> > > has been assigned sudo permissions to run the package manager" and one
> > > doesn't really need a long article to prove that it's not secure.
> > I think the article is interesting nonetheless. Some people may think
> > that granting sudo on apt is OK. In the past, I think "apt install
> > ./something.deb" was not possible.
> Random thought: could it be possible to restrict non-sudo users to
> installing packages from repos that are signed by a GPG key that is already
> trusted by the system (the Debian archive key)? 
Via some wrapper maybe? But at that point just use PackageKit?

> That way this attack could not be carried out. 
Only the one that relies on package content, while there are more ways to
ask apt to run a process, as listed in the article and in this thread.

> Then add a Unix group that allows apt installation from
> trusted repos, make apt setuid 
Please don't.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#100970

Timothy M Butterworth:
> All,
> 
> I just ran across this article
> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
> the attacks on Debian 11 and they work successfully giving me a root
> shell prompt.
> 
> Tim
> 

Hi Tim,

All of the attacks presented assumes that the local user has "sudo"
permissions to run apt and use that as the basis for escalating
privileges (not commenting on yum or snap).

I think it is a good demonstration of how some sudo policies are too
lenient and can be exploited.  Though I am not sure this is a bug in
apt, as I do not think apt ever promised to be "safe" to use from a
constrained sudo policy.

Note that the blog post itself also mentions this:

"""
[...] In certain cases the user should not be a root/admin user but has
been assigned sudo permissions to run the package manager only for
package management purposes.

We’ll look at how this permission can be abused to gain root access to
the machine via a root shell.
"""
(from the "Introduction")

My reading is that "this permission" refers to the "assigned sudo
permissions".

Thanks,
~Niels

[toc] | [prev] | [next] | [standalone]

#100973

[Multipart message — attachments visible in raw view] — view raw

On Thu, Aug 12, 2021 at 01:12:37AM -0500, Brian Thompson wrote:
> Would you agree that there is an issue with sudo access that is enabled
> by default on most Debian and Debian-based distributions? The bug may
> not be in apt, but it definitely lives somewhere.
Do you think "sudo access" itself is a "privilege escalation attack"?

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#100975

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, 2021-08-12 at 11:19 +0500, Andrey Rahmatullin wrote:
> On Thu, Aug 12, 2021 at 01:12:37AM -0500, Brian Thompson wrote:
> > Would you agree that there is an issue with sudo access that is
> > enabled
> > by default on most Debian and Debian-based distributions? The bug
> > may
> > not be in apt, but it definitely lives somewhere.
> Do you think "sudo access" itself is a "privilege escalation attack"?

I do not. I think that the possibility of dangerously configured sudo
access is a vulnerability.
-----BEGIN PGP SIGNATURE-----

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEUvsITHGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2GffuzD/9+1W9z3AA/DFy5HgBgV5ntSiP6hhQ4
PdybHxQ1zP7A4uZHdGV4IqsfOKWkuhnzV/dA5Rpk7pvT1iWDQgkz7uEK5HXkQT4N
QCg3MeBbqdDpqG5UakVnyu+qGJ26pRyQYmq54dZOUFmNJL8uF5BwnPg7d4NWikds
0e2QrYtyaFFVaInhDHE7uM+eYQtmWSP5yXYxGy9RLjUpLB1SPqAxeR4bZxeJ2yAz
873L1VpWOHbmxsRZj6NRH6dh2o87fqAq1BcnJZrLpbm38YKIE8PKtaNjKlhFLItt
hwnGPJfobrxGG4gPgwJBB2S+FP+K6kWxSSA9y1lpAo+kLZlZFENWWxnGpgBIZ2+Q
DZTFM6nPkwAvWLz1rpP5tf9Kqa7ABLyHnHdNqHAd44VtihCjwFkRtzPQgoysPGux
nghHMpCmdYXuen6xaPaDSvR5emy6XVuuYvEBVjGMtR4VwJsYwgLOv1hbh+yN+fTx
ItpwQjOXsD0PgGPs5BjF2G2aGHiVcHLuAZ6q0JbBo+QsCC5T3cDEJyPyuImRpNUX
zQ9oyA8crGO5kq/7qz1I8/mMBrbaHKtgI9sCwwOwT56EUCvN2J0VcQGgrqQ0mVEB
fJnCJFGlBrixpwbrMOik/P4QtibprVh070MgATb0QunTxyJLvnC3y/1XySkRCY8j
eLvWe2IBKBalmw==
=4yEj
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#100978

[Multipart message — attachments visible in raw view] — view raw

On Thu, Aug 12, 2021 at 01:25:06AM -0500, Brian Thompson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On Thu, 2021-08-12 at 11:19 +0500, Andrey Rahmatullin wrote:
> > On Thu, Aug 12, 2021 at 01:12:37AM -0500, Brian Thompson wrote:
> > > Would you agree that there is an issue with sudo access that is
> > > enabled
> > > by default on most Debian and Debian-based distributions? The bug
> > > may
> > > not be in apt, but it definitely lives somewhere.
> > Do you think "sudo access" itself is a "privilege escalation attack"?
> 
> I do not. I think that the possibility of dangerously configured sudo
> access is a vulnerability.
Yet you are talking about "sudo access that is enabled by default".

Or are you saying sudo access to apt is enabled by default on most Debian
and Debian-based distributions?

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.devel

csiph-web