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

Reindl Harald h.reindl at thelounge.net
Tue Apr 29 21:09:27 UTC 2014

Am 29.04.2014 23:00, schrieb Chris Adams:
> Once upon a time, Reindl Harald <h.reindl at thelounge.net> 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"


> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140429/6f658cc1/attachment.sig>

More information about the devel mailing list