
The Confused deputy - zenincognito
https://css.csail.mit.edu/6.858/2012/readings/confused-deputy.html
======
bascule
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...](https://www.sektioneins.de/en/blog/15-07-07-dyld_print_to_file_lpe.html)

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

[https://en.wikipedia.org/wiki/Confused_deputy_problem](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...](http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=05B9D6A048D54131F4AC48471147C49F?doi=10.1.1.6.3660&rep=rep1&type=pdf)

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.

------
caf
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.

------
Retric
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.

~~~
bascule
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.

~~~
Retric
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.

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

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

~~~
gruez
ie. CSRF

