Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Am 29.04.2014 23:00, schrieb Chris Adams:
> Once upon a time, Reindl Harald <h.reindl@xxxxxxxxxxxxx> said:
>> google as example for CVE-2014-0038 and as i already explained
>> you: a attacker has no shell, you have two ways to force a existing
>> local exploit by a web-application:
>>
>> A: try to get a complete script on the machine and execute it
>> B: find a very likely present binary and bring it to do the
>>    rest of the attack for you with arbitary input
> 
> If I can run arbitrary code as your web user, I can do whatever 
> your web user can do

limited (why limited goes way too off-topic)

> If your kernel has a security hole, I can exploit that

surely, the point is how easy i can do that, do the instructions
somewhere how to do that work or not because they contain a
command / binary not available on the target system

> If I can run PHP code, there's a million things that I can do.  If I can
> run shell code, I can do just about as much.  How does the existence of
> a non-privileged systemd binary affect that?

given index.php?dumb_param=exploit_code

dumb_param gives exploit_code to shell_exec() or like function
you can't do whatever you like here simply be escaping

so you are very limited with your command
finally you need a abstraction in form of a binary doing harm with
the input which you can't pass directly to shell_exec limited
by input quoting

> I understand "defense in depth"

good

> I just don't believe the existence of a
> non-privileged systemd binary has a non-negligible effect on system (or
> container in this case) security.  If I can run an arbitrary binary on
> your system, you are already owned.  I can run /bin/sh (for example,
> just because it is nearly universal) and fetch other arbitrary binaries.

as explained you can't do that in any situation

> Do some binaries being available possibly make an attack easier?  Maybe,
> but that work is generally figured out once by "smart" people, and then
> exploited a million times by script kiddies.  Something being "harder"
> doesn't add anything mcuh to security, because it _can_ be figured out,
> will be, and then it'll be copy&pasted repeatedly (and you haven't
> gained a significant advantage from "it is harder")

surely because the copy&pasted instrcution may not work if it
relies on a default binary not installed in the container

in that case the attacker needs to adopt the exploit only for
you or he just goes to a server where his exploit code works
out of the box

Attachment: signature.asc
Description: OpenPGP digital signature

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux