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
