Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment Re:Misleading and Hyperbolic Title/Comparison (Score 1) 129 129

I hate to repeat myself, but: Any exploit that allows execution of code in a user's own context can be escalated to root access by this exploit.

So.. Your PDF reader has an exploit that allows code execution. Without the dyld bug, the PDF bug only allows code to execute in the user's context. With the dyld bug, the PDF bug can give itself passwordless sudo access, and execute shell commands as root.

Comment Re:You're welcome (Score 1) 129 129

Apple clearly forgot to sanitize the new DYLD_PRINT_TO_FILE

They also forgot to set the close-on-exec flag for the file they open. If they had done that, then at least only the SUID application would be a target, instead of the SUID application and any child process.

which outputs the string "$(whoami) ALL=(ALL) NOPASSWD:ALL" into fd 3

Actually, $(whoami) will be executed and its output substituted by the shell. The username of the user will replace that string, so root access will be granted by sudo only to the user that runs the exploit, not to all users. This would give root access to all users:

echo 'echo "ALL ALL=(ALL) NOPASSWD:ALL" >&3' | DYLD_PRINT_TO_FILE=/etc/sudoers newgrp; sudo -s

Comment Re: How the hell does this get into live software? (Score 1) 129 129

I think even Linux was affected at one time.

Yes. The Linux dynamic linker had a list of environment variables that it cleared when executing in a SUID context, for security. A comma was removed from the list, which caused the compiler to concatenate two of the strings. The result was that neither of those two variables were cleared, and so "LD_PRELOAD" could be used to load a replacement shared library into a SUID binary.

Comment Re: But can it be a Tweet? (Score 3, Informative) 129 129

When you run the example exploit command (simplified):
Your shell sets the DYLD_PRINT_TO_FILE variable.
Your shell executes newgrp. newgrp is SUID root.
As newgrp is initializing, the dynamic linker opens the value of DYLD_PRINT_TO_FILE (/etc/sudoers) for debug log output. It should check whether it is executing in a SUID context, but doesn't. It should also set the close-on-exec flag for that file, but it doesn't do that either. The log file is now file descriptor 3.
newgrp sets its uid and gids as appropriate for the calling user, and then starts a new shell. Because the close-on-exec flag wasn't set, the new shell still has /etc/sudoers open as file descriptor 3.
The new shell reads commands from stdin. In this case, it gets "echo "$(whoami) ALL=(ALL) NOPASSWD:ALL" >&3".
There is no more input, and the shell exits.
Your shell runs sudo. The sudoers file has been modified, and now says that you have the right to run all commands without being prompted for a password.
You get a root shell.

Comment Re:Misleading and Hyperbolic Title/Comparison (Score 1) 129 129

Furthermore, local access pretty much is the end of the road anyway.

Physical access is usually the end of the road. This exploit doesn't need that, it just needs shell access. Any exploit that allows execution of code in a user's own context can be escalated to root access by this exploit.

Comment Re:Nails are death knell 2015 (Score 1) 250 250

The arstechnica article is bull. AOSP is alive and well, and in no way is Google trying to extinguish it. The complaints in the arstechnica article mostly boil down to the fact that Google provides components that interact with its cloud services which aren't open source because they aren't useful except as an interface to those services. They're useful, but not essential to the operating system.


Old mail has arrived.