4 ms·

Title is a little generous about "hidden", the exploit revolves around API & Framework used to power the parts of the control panel, and its authorization schem

by pquerna 12y ago

Title is a little generous about "hidden", the exploit revolves around API & Framework used to power the parts of the control panel, and its authorization scheme being broken. I do think its too bad that setuid binaries don't have additional restrictions, like 100% must be code-signed or must be run in a sandbox-exec[1] based on that signing. [1] - https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man7/sandbox.7.html#//apple_ref/doc/man/7/sandbox https://developer.apple.com/library/mac/documentation/Darwin...

smackfu 12y ago
Isn't the "hidden" part related to them being a private API/Framework?
AnthonyMouse 12y ago
Code signing is not interesting. If normal people can get their code signed then so can the attacker and if they can't then it locks you out of your own computer. The only thing code signing is really good for is to verify that an update to a program the machine's owner installed was signed by the same author as the original program, and unfortunately it's rarely implemented that way. But that's not really what you're asking for anyway. You can assign granular permissions to binaries regardless of code signing. The real problem is there are so many things that aren't literally root but are effectively equivalent because if you can do them then you have easy privilege escalation. That's why the Windows security model is so silly. An administrator is not allowed to 'su' to another user without the user's password but any reasonable subset of the administrator's privileges can be used to silently cause any user to execute arbitrary code, e.g. by setting their login script or putting executables in the All Users startup folder or just loading a kernel driver that will let them do whatever they want.
- superuser2 12y ago
  >then so can the attacker Maybe, but the attacker can also get their certificate revoked when their activities are discovered.
  - AnthonyMouse 12y ago
    ...if their activities are discovered. And then the attacker just gets another certificate under a different name, or steals somebody else's certificate. Ignoring, of course, that revocation is totally broken. It cannot simultaneously be easy for anyone to get a certificate and hard for an attacker to get a certificate.
- wfunction 12y ago
  > That's why the Windows security model is so silly. An administrator is not allowed to 'su' to another user without the user's password but any reasonable subset of the administrator's privileges can be used to silently cause any user to execute arbitrary code That's like saying kernel memory protection is silly when the user is an admin because he could just as well load a driver into the system to wreak whatever havoc he wants. Yes, he could. No, it's not silly.
  - AnthonyMouse 12y ago
    Memory protection is not silly. Not being able to bypass memory protection (and therefore prohibiting all manner of debugging tools) is silly, and that is the appropriate analogy. If a user correctly has permission to do a thing via a series of ugly hacks then there is no reason not to just let the user do the thing directly.

by pquerna 12y ago

smackfu 12y ago

Isn't the "hidden" part related to them being a private API/Framework?

AnthonyMouse 12y ago

Code signing is not interesting. If normal people can get their code signed then so can the attacker and if they can't then it locks you out of your own computer. The only thing code signing is really good for is to verify that an update to a program the machine's owner installed was signed by the same author as the original program, and unfortunately it's rarely implemented that way. But that's not really what you're asking for anyway. You can assign granular permissions to binaries regardless of code signing. The real problem is there are so many things that aren't literally root but are effectively equivalent because if you can do them then you have easy privilege escalation. That's why the Windows security model is so silly. An administrator is not allowed to 'su' to another user without the user's password but any reasonable subset of the administrator's privileges can be used to silently cause any user to execute arbitrary code, e.g. by setting their login script or putting executables in the All Users startup folder or just loading a kernel driver that will let them do whatever they want.

superuser2 12y ago
>then so can the attacker Maybe, but the attacker can also get their certificate revoked when their activities are discovered.
- AnthonyMouse 12y ago
  ...if their activities are discovered. And then the attacker just gets another certificate under a different name, or steals somebody else's certificate. Ignoring, of course, that revocation is totally broken. It cannot simultaneously be easy for anyone to get a certificate and hard for an attacker to get a certificate.
wfunction 12y ago
> That's why the Windows security model is so silly. An administrator is not allowed to 'su' to another user without the user's password but any reasonable subset of the administrator's privileges can be used to silently cause any user to execute arbitrary code That's like saying kernel memory protection is silly when the user is an admin because he could just as well load a driver into the system to wreak whatever havoc he wants. Yes, he could. No, it's not silly.
- AnthonyMouse 12y ago
  Memory protection is not silly. Not being able to bypass memory protection (and therefore prohibiting all manner of debugging tools) is silly, and that is the appropriate analogy. If a user correctly has permission to do a thing via a series of ugly hacks then there is no reason not to just let the user do the thing directly.