Security issues with sudo

I posted the issue described bellow in a post on ubuntu forums. They closed my thread in a few hours so I am reposting it here so that you can comment on it. If I don’t get some reasonable feedback from the linux community until next week I will publish code and step by step instructions on how to use it.

1. The problem
In Ubuntu gksu and sudo can be hijacked by an attacker who already has access to the current non-administrative default account. In order to do that you can simply create a bin directory in your home folder, add that directory to PATH and create in it the scripts: gksu and sudo. The scripts would silently run any application the attacker wants with root privileges and start the application you wanted to start in the first place so that you won’t notice a thing.
So, after the attacker application (got on a website with a firefox bug for example) gets access to your limited default account all it has to do in order to get root access is the above and wait for you run something with administrative rights (like synaptic from the menu; at some point even the updater which runs automatically was calling gksu with a relative path). This largely defeats the purpose of having a limited account on a desktop version of Ubuntu. The code to do this is very simple and even a script kiddie can make it if he doesn’t find it somewhere on the internet.
I did test multiple times the things I said above.

2. The do it right solution
I don’t know how to fix sudo but for gksu I have an idea and I posted it on the gksu bug I submited a year and a half ago. Even if you set a description gksu should show the complete path of the application it is running. The presence of the description still leaves easy social engineering attacks (people don’t read all the text in a form or they don’t understand linux commands) but an advanced user has a chance to realize he is hacked. A more complete solution would require not being able to modify menu entries for administrative applications and, of course, having absolute paths in those menu entries.
Sudo solutions might go in the direction of modifying the most used terminal in order to treat sudo specially but I find that very problematic. The simple, working, correct solution is to also lock the screen and show what you are executing.
There might be a system wide solution for any administrative start commands in a way that the system (kernel and some base applications) treats differently the sudo/gksu type of commands. It would not use the path to search for sudo but only its predefined location and the path used for the applications sudo runs would be only changeable with root access. But I understand too little about linux as a whole in order to realize all the implications of this.
There also is the simple and very restrictive solution of not having local user paths, only paths that are modifiable by root access.
The use of unlock on some ubuntu applications (User settings) puzzles me. The password prompt you get there does not lock the screen and it seems that you don’t have a way to realize if it is the system asking you the password or an applications that looks just like “user settings” (it is very easy to create clones in open source). I haven’t looked deeper into unlock but superficially it doesn’t look like a solution for gksu problems.
Any solution without having an administrative (locked, grayed out, something that only a root application can do) screen where to enter the password and see exactly what you are running is prone to attacks where the random dialog appears and asks you for password (maybe it knows that you are running synaptic and somehow expect to be asked about password).

3. The sad solution
No gksu and sudo. Users log out and log in as root for administrative stuff. Of course they will end up using only root and here the limited account “protection” stops.

4. The “great new thing” solution
Get rid of the default limited user account on desktop installations. Even if that user account works properly in connection with doing administrative jobs its limitation don’t prevent an attacker to do damage where it mostly matters for you. For 99% of the users their documents and most other things they care about are accessible/modifiable with the limited user account. This includes those secret pictures you have with your new girlfriend. Browser settings can also be altered without administrative rights, and of course browsing history, cache and saved passwords are not locked behind the “root door”. There are things that the malware can’t do on limited accounts like sniffing, key logging, reading your credit card from firefox memory but attackers can find creative ways around these limitations (can’t they install addons without root access? don’t those addons get to the firefox internals?).  For me, the part of the system for which I need root access is the part I care less about. For instance I installed the version of Ubuntu (9.04) I am talking from 2h ago (45 min of my time I think). On my desktop system (doing usual stuff: internet, music, pictures) if an attacker gets from limited account to root access he mostly can hide better from me (rootkits). But I am not really searching for him so I won’t find him anyway.
As for limited access preventing users and applications to do stupid things. Users are not prevented too much to mess their system by root access (they need to type “sudo rm -fr /*” instead of “rm -fr /*”; saving a document in / by accident is not the biggest problem in the world; for deleting system files they could be prompted anyway). User applications are prevented to arbitrarily break the system but there is a long time since I’ve seen an application trying to break my system in any place other than the installer. Its true that default root access would allow applications to grow more ill behaved (like saving user settings in /usr) but we might find solutions for that without using a default limited account (at least not as limited as it is now; minimal set of restrictions, warnings, etc for properly behaving applications).
On Windows XP when I do not trust an application I get from the internet I do run it under a limited user account I created specifically for that purpose. That user account does not have access to my documents, my desktop, settings or anything else that matters for me. Things I save from that application go to that account documents and I copy them later from that location. People see me as an advanced user and, still, I have to admit that I don’t find the method easy to use. But if the operating system would create such a user account for me and offer me some really easy entry points to it when I might need it (like asking: do you want to run this internet application: yes, no, under limited account.) I would use it all the time. Firefox can also be run under a special limited account (you could still save files only in a predefined location), maybe each tab in its process like chrome with higher limitations if you go on some blurry web sites (enabled for private browsing?).
I have installed my Windows XP system 3 years ago, I use it a lot and I like to experiment new things but still I haven’t broken it. I did reinstall some linux systems in the mean time (it is related with understanding less linux (I did the “hard” windows experiments 12 years ago), going deeper into the system (I use sudo all the time), but mostly it is problematic updates (especially distribution upgrades)).

5. Linux security fundamentalists please read the above twice before posting :).

 

Edit 2018-03-04:

This post was influenced by a popular confusion at the time related to the role of gksu or sudo on Linux. It seems they were never intended to reach a similar level of root system protection as the Windows UAC (configured at maximum security), although many users intuitively assumed so. As one commenter noted, Linux has a different meaning for administrator and root and the whole problem could be described as a by design weakness, but not necessarily a vulnerability.

The default user account in Ubuntu was actually a Linux administrator which, while limited by default, could allow running applications as root after giving root password to a gksu prompt. The protection of gksu or sudo seems useful mostly for accidental system break in the absence of a more specific protection for system files.  There is some adversarial security usefulness by closing some opportunity windows and delaying an attacker that could get temporary access to the main account used by the system administrator.

At some point gksu, sudo or their replacements could get better security to reliably handle a wider range of attacks. Without some form of password prompt seal (secret image or information to recognize a genuine prompt) or an equivalent of Ctrl-Alt-Del, any full screen application may fake the password prompt.

gksu is now deprecated. I did not look closely enough on its replacements to comment on how much has been improved.

A variant of the “great new thing” solution was already implemented by google chrome in a technically feasible way. Root escalation exploits are so common that there may never be an effective solution to protect the root system without severely restricting the attack surface area (extreme limiting of what the user account or process that runs the potentially vulnerable code can do). Ubuntu has a guest account now, which looks interesting for the purpose, but I did not look closely enough at the implementation.

Errata:

• “non-administrative account”: meant non-root, but it was the default Ubuntu account that could be used to do administrative tasks using root password or even its own password (more common now). It was actually a Linux administrator (sudo) account.
• “limited account”: meant the default Ubuntu account. It could be used to do administration after a password prompt. Root can do it directly, without any prompt. In Linux “limited account” is more commonly used for accounts that can’t do any administration. For those accounts even if the user knows the root password sudo can’t be used. Only switching the account may be used.