The built-in terminal is not set read-only

[Philip Van Hoof]

Binary package hint: update-manager

The build-in terminal is not set read-only and a user can therefore send characters to the terminal. This is insecure and the user can interrupt the upgrade procedure using the keystroke CTRL+C (and/or cause other interruptions).

It wouldn't surprise me if a user could this way inject commands but I haven't yet tried that. Since the tools runs with administrator priveledges and since I can imagine some administrators making it possible for their users to run this tool (for example by manipulating sudo) and/or since this could be used by a malware software to run the program (sending the password using caught passwords by listening on the X11 keyboard) and rapidly sending such a CTRL+C to get administrative priveledges, I'm confident this bug should be marked as critical at least.

[Philip Van Hoof (pvanhoof)]

I can try to do a prove of concept for this one. I believe the shell process that runs the apt-get software should be the ONLY ONE that runs under root priveledges. The UI shouldn't as there's multiple security issues with Gtk+ programs.

Using a pipe you can very easily achieve that. You could also create a very simple helper application that sends-back information like the progression information and/or the output of the terminal. This is the proof that the complete tool is being run as root:

root 7221 1.2 6.7 99940 70132 ? Ssl 10:36 0:07 /usr/bin/python /usr/bin/update-manager

Ubuntu is very lucky it doesn't have people like me trying to write malware. I could probably create a tool that would gain root priveledges in 50 minutes. This is total insanity and extremely insecure.

[Martin Pitt (pitti)]

Welcome to the world of running root programs under X :( The injection of X events into running root applications is generally feasible. It is even more easy to ptrace() all user's processes and try whether they have a sudo tty ticket. The latter method is even easier and just requires 10 lines of shell and an installed gdb.

Therefore I unmarked this as security/private, since it is nothing special. I keep it open since it might be fixed in Feisty. However, I believe that it does make senese to not make the terminal read-only, because sometimes dpkg asks conffile questions, and some broken packages might even ask interactive questions without using debconf.

I leave the judgement of whether to keep this open to Michael.

[Philip Van Hoof (pvanhoof)]

Just as that it's possible to run, as a user, an xterm and change to the root user using, for example, su or sudo, it's still not needed to run the entire thing as root. Even a very simple sudo-line or a +s binary could solve this in a few minutes.

The problem is not only that you can inject characters, which certainly is a problem by the way, but also that a tool that uses a huge amount of libraries that haven't ever been tested nor reviewed for security is being used while being ran as the root user.

It's very easy to run the terminal component as user, and run the software in it as root. I don't see any reason why to run everything as root (except being lazy and trying to take the easy route, which is exactly how another popular operating system builder has got himself into troubles).

The right solution could be a library that implements asking these questions, and dlopen()-ing an implementation for X11 or one for the console. Depending on the situation. And then simply reject packages that do broken things.

It's not the user of your software's fault that you picked Debian packages and that Debian packages can ask questions on the terminal. Therefore you shouldn't put this security burden on the users of your softwares (and still claim that Ubuntu is capable of serving users that require security, for example in the server room, which is what Ubuntu (the distribution) does, right?).

Putting the security burden on the GNOME, Python and gtk+ community (which includes me) also isn't the right track. That community has no such focus (they don't want to care about the same issues that the server software developers have to care about -- like, but not only security).

You also don't know what security problems future releases and new features might introduce. Nor does that community pay a lot attention to that.

Integration is Ubuntu's task. Making sure it's at least a little bit secure, too.

But feel free to close this bug and ignore it. Time and an almost certain exploit will be your judge.

[Philip Van Hoof (pvanhoof)]

> The right solution could be a library that implements asking
> these questions, and dlopen()-ing an implementation for X11 or
> one for the console. Depending on the situation. And then
> simply reject packages that do broken things.

Note that the implementation should or could use an IPC to pass both the question and the answer around between processes (one being ran as root and the other being ran as the user). Because also the GtkDialog-code that would be used in such an X11 implementation, would be a security risk if you'd ran it as root.

[Ernst Kloppenburg (ernst-kloppenburg)]

with my current edgy->feisty upgrade, all debconf questions are asked in the terminal because all other frontends failed. Without the terminal being accessible I were in a quite bad situation.

Therefore, before setting the terminal to readonly, the availability of a gui debconf frontend would need to be checked.

[Michael Vogt (mvo)]

One open task is enough.

[Michael Vogt (mvo)]

The fact that the terminal is not read-only is deliberate as some packages ask questions in their maintainer (postinst etc) scripts using commands like "read". Because there is no policy that forbids this, we have to support it.

[Martin Pitt (pitti)]

Well, using console input is indeed not allowed (Debian Policy 3.9.1), the only sanctioned method is debconf. Since u-m intercepts debconf questions and displays them in a separate dialog, most packages should work fine without a r/w terminal.

However, that of course does not change the fact that a few packages still use console input.

My argument that this is not the slightest bit of extra vulnerability still stands, though. If you have the power to execute u-m through sudo, and install packages, then anything lurking in the background can execute stuff as root unnoticed, regardless of whether u-m has a writeable terminal or not.

[Philip Van Hoof (pvanhoof)]

Although I do agree with your argument, I still believe it's important to continue removing the need for console input (and eventually fully replacing it, and disallowing writing to it by default or something).

The reason for that is that the Administrator would not expect that possible malicious software that runs in the background as his user, can harm the system when he's logged in (for example when trying to install anti such software). With the editable terminal widget, I suspect that it's perfectly doable for such software to cause damage to the system easily.

Although, yes, a root xterm or terminal makes this possible too. But in this case the Administrative user, while being logged in, is perfectly aware of that situation. With a standard Ubuntu tool like the software updater exposing the exact same dangers, this is a lot less clear to the Administrative user.

[Robert Roth (evfool)]

Isn't this the duplicate of bug #3718?