Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
The Confused deputy (csail.mit.edu)
41 points by zenincognito on July 26, 2015 | hide | past | favorite | 9 comments


The recent OS X DYLD_PRINT_TO_FILE local privilege escalation vulnerability was a classic confused deputy:

https://www.sektioneins.de/en/blog/15-07-07-dyld_print_to_fi...


Wikipedia has a lot of examples of this problem in action here:

https://en.wikipedia.org/wiki/Confused_deputy_problem

Details on how to prevent the issue and others in capability systems are described here:

http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=05B...

One can try to apply those principles to other areas where this problem shows up. Should help unless the constraints enforce broken designs as many legacy technologies do.


This is why in UNIX-like systems, file/device permissions have to be checked using the authorisation that was in place at open() time and not at write() / read() time; this allows passed or inherited file descriptors to function like capabilities in this sense.

For example, when you run a setuid binary, it inherits file descriptors (stdin, stdout and stderr) that were opened by the caller - to prevent a certain class of confused deputy attacks, writes and reads on these file descriptors should not use the elevated privileges of the binary but the original privileges of the opener.


I am guessing this is from 1987 ish?

I would also suggest that a huge class of issue stem from unified permissions so any access means total access. Unix goes for CRUD (Create, Read, Update, Delete) which has become fairly standard, but often adding a new class of permission like Append (for log files) simplifies a lot of security issues.


That's not really what the confused deputy problem is about.

Instead, a confused deputy has too much authority, and is being asked to "switch hats" and pretend to have the authority of a user/caller.

Confused deputies arise because they don't have a clear picture of what the authority of the user/caller actually is, and accidentally expose some authority that the user/caller wasn't supposed to have.

Capabilities let you model this authority as a first-class principle.


In principle that's true, but let's consider something like auto run when inseting a USB or CD etc. When auto run means full user permissions to run any program that's a huge security issue. If on the other hand auto run is specifically a dialog box based on the device format that's a much smaller security issue.

The point being if you give an app permission to add a charge to a bill and only add a charge to a bill then the fact a user can increase there bill in an arbitrary fashion is still a problem, but it's a smaller one than letting them delete all charges.


It seems like this is the equivalent of making the compiler a setuid program, which nobody would do nowadays.


That's true, but confused deputy problems are still an extremely common class of issues, if not the most common.


ie. CSRF




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: