I've been reading this. Apparently I would gain root access if I hold down enter (somewhere) for 70 seconds. I tried it on a password prompt but it gave me like 3 attempts and stopped. I tried it on a tty but it didn't work also. Am I not vulnerable or am I doing it wrong?
Ubuntu – Test whether Ubuntu is vulnerable to (CVE-2016-4484)
rootSecurityvulnerability
Related Solutions
Well, there are two separate aspects in running an application as root; one of them improves security and another one may compromise it - I think mixing those two aspects explains your confusion.
running an application as another user (possibly root user, but not necessary) makes it more difficult for another process to access files owned/created by that application and do other nasty things (send a KILL signal, for example). This is good.
if an application happen to have a vulnerability (i.e. sending it some specially formatted input makes it to execute some code via buffer overflow etc.) - then, after exploiting the vulnerability, the attacker will be able to execute code with the privileges of that process. In this sense, running an application with root privileges is BAD, because it would give the highest level of privileges to attacker.
Now you understand that running update manager as root may be bad if it contained a bug which would allow a specially-crafted .deb file to crash it and make it to execute some code. However, running some applications, such as package manager, with superuser privileges is unavoidable because they modify the essential parts of the system.
The common solution to this problem is to perform so-called "privileges drop" on program startup; this is often used to run webservers and other potentially exploitable (and accessible from outside) software. The idea is simple: the program starts as root, but as soon as possible it switches to some user account with as little privileges as possible (no shell login, chroot-ed to its home directory etc.) This way, even if compromised, it would give attacker a very limited access to the system. Also, other user accounts (except the superuser) will have no access to the application's files
I'm not sure how easy would it be to run a desktop application like this though.
Actually, in this situation I think running web browser as a non-privileged user would make more sense. And, of course, Google gives us a few links on the subject:
Taking this idea to the extreme (as you're suggesing in the comments) will give you a system which is similar to how Android works; on Android each application operates within its own user account, so it only have access to its own files. This probably have some problematic areas in Ubuntu, i.e. if you downloaded a file using Firefox running in a restricted account, it'll only be able to save it in its own home folder so it won't be possible to open the file in a text processor (which runs as another user)...
Regarding the launcher script I would imagine the script will be starting as root and invoking the applications as their respective users. The script will obviously need to be writeable by root only. Read about setuid.
Warning; not tested because I think it's not such a great idea, even for a VM (bad habits are difficult to remove...).
I think this is a PAM thing (PAM=pluggable authentication modules).
In /etc/pam.d there are all the PAM configuration files that tell the system how to do the authentication of users. Now, the module that check for the passwords "unix style" is pam_unix.so, in which man page you can find among the options:
nullok The default action of this module is to not permit the user access to a service if their official password is blank. The nullok argument overrides this default and allows any user with a blank password to access the service. nullok_secure The default action of this module is to not permit the user access to a service if their official password is blank. The nullok_secure argument overrides this default and allows any user with a blank password to access the service as long as the value of PAM_TTY is set to one of the values found in /etc/securetty.
So I suspect is a matter of finding all the occurences of pam_unix.so in the files above, and add the option nullok (or change the nullok_secure to nullok) to the entries.
According to this post the file should be /etc/pam.d/common-auth --- but I am not sure about this because in Ubuntu the VC are in the /etc/securetty list so the null password for root should work from there (although not from a terminal emulator), and the SO states it doesn't work.
So a bit of experimentation will be needed ;-).
Best Answer
See the security website from Canonical on this. All releases have a "needed" so there is no fix yet for them.
So if you match the conditions for this bug you can affected. For 1 you need to be using Linux Unified Key Setup (LUKS), cryptsetup. So your partition needs to be using encryption. If you do not ... you do not have a problem. (More info at hmarco.org)
The fix is rather easy, just run this commands to add panic parameter to your boot configuration:
panic=5to your options preventing this problem. This is the number of seconds you want to initiate the reboot after the panic. Adding thepanicparameter to the kernel entry in the grub configuration will prevent a shell.