190

Your points are all good, and you are correct, but before we get outraged about it we need to remind ourselves how the linux security model works and what it's designed to protect. Remember that the Linux security model is designed with a multi-user terminal-only or SSH server in mind. Windows is designed with an end-user workstation in mind (but I've heard ...


91

No, this is not correct. While one may argue about the relative difficulty of finding and exploiting 0day vulnerabilities on Linux when you have local access, the security architecture itself of a modern Linux system (with an MMU) is designed to isolate different users and prevent privilege escalation. A non-root user cannot gain root without proper ...


59

There is a race condition inherent to the way shebang (#!) is typically implemented: The kernel opens the executable, and finds that it starts with #!. The kernel closes the executable and opens the interpreter instead. The kernel inserts the path to the script to the argument list (as argv[1]), and executes the interpreter. If setuid scripts are allowed ...


58

Even if you wanted to, I don't think you can remove the root user. From Wikipedia: On Unix-like systems, for example, the user with a user identifier (UID) of zero is the superuser, regardless of the name of that account. and a lot of the kernel code that vulnerabilities exploit does stuff like // become root uid = 0; ... if (uid == 0) // do some ...


39

A user on a Docker host who has access to the docker group or privileges to sudo docker commands is effectively root (as you can do things like use docker to run a privilieged container or mount the root filesystem inside a container), which is why it's very important to control that right. Breaking out of a Docker container to the host is a different game ...


33

Is there any safety mechanism in Linux in general or Ubuntu specifically which prevents any application from displaying a dialog which looks identical to the system's one, asking me for my password? Quick answer: No. From the perspective of the user, there is no guarantee that the prompt comes from the operating system; it could be any malicious ...


29

What you need is relatively simple: you need to ensure that your students' unprivileged accounts are well confined. If you don't have a graphical environment involved, your situation is relatively simple. You should start by implementing the following actions: ensure users are created without administrative privileges (no sudo, no admin or wheel group) ...


27

As argued by others, it makes no sense to "remove" the root UID (which is represented on UNIX as the UID 0). I would go even further and state that it makes no sense to freeze a system into not having any means to provide new privileges. Note that this answer is very opiniated and vague, because the topic to cover is enormous. Let's first go through what ...


26

To rephrase the quote - Privilege escalation vulnerabilities have existed and will continue to be found or created. During the last week we have this little doozy in SystemD; what are we going to have next week, will it be patched in time, and how good is your patching regime? You should assume that it's feasible that an attacker who can run on a box can ...


21

It's All About the Security Model We see reference to "Checking for jailbroken/rooted device" in nearly all Mobile Application Security Checklists (e.g OWASP). When comparing it to desktops or web browsers we have to keep in mind that they have different threat models. For example on desktop machines when designing an application we already know that there ...


21

Yes. This is insecure! I personally always Cancel that dialog. Not because it could be fake, but because it could be real. I am supposed to give escalated privileges to "an application" just because it asks? No, I don't think so. System updates are fine, I do those manually, but it annoys me that the error reporting system requires this. Bad design.


19

Passwords are normally stored in /etc/shadow, which is not readable by users. However, historically, they were stored in the world-readable file /etc/passwd along with all account information. For backward compatibility, if a password hash is present in the second column in /etc/passwd, it takes precedence over the one in /etc/shadow. Historically, an empty ...


14

Primarily because Many kernels suffer from a race condition which can allow you to exchange the shellscript for another executable of your choice between the times that the newly exec()ed process goes setuid, and when the command interpreter gets started up. If you are persistent enough, in theory you could get the kernel to run any program you ...


14

Exploiting a privilege escalation vulnerability is already hard enough, doing so while being certain that you don't leave a trace is much much harder. An Android user trying to root their phone can keep trying one exploit after the other, without worrying or having to cover up their traces. A student repeatedly trying to abuse sudo or spreading fishy ...


13

This is extremely insecure. I'm glad you asked elsewhere before running this setup yourself! I hope those 3000+ people on AskUbuntu were similarly cautious. So, why is this insecure? What can an attacker do if you put them in the group? That group will be able to elevate privileges to root. The reason is simple: VeraCrypt allows mounting an encrypted volume ...


12

In a Penetration test,you can root a server if you are permitted to do. The question cannot have a generic answer. It can only be specific to a each case. The Rules of Engagement specify whether or not you can root a server. A few things are considered for this: Is the server a Production one? If yes, then certainly you should restrain from rooting it. If ...


11

Contrary to what you feel, the (modern) Windows and Ubuntu ways of handling privilege levels and privilege elevation are fairly similar. The reason is surely that the operating systems are both multi-user systems with similar use cases which face similar problems. Both operating systems restrict what an ordinary user can do (by running programs, of course). ...


10

Background That message is from the basic header that every Windows (PE format) executable has. The message (and the code that displays it) is technically editable, but all compilers seem to just emit code that displays that same string and then exits. It's 16-bit executable code (like a DOS .COM file), intended to be displayed when you try to run the ...


9

Nothing. If you cannot trust your hardware, you cannot trust it. There does not exist a universal way of updating keyboard controllers, and certainly there is no universal introspection for them. While you could reflash those keyboards that are reflashable every time the system boots or a keyboard is plugged in, you'd have to come up with a way to do this ...


9

There's this saying that using a DDOS-attack, people first attack a server using millions of concurrent requests and by doing that they miraculously gain access to the server. I think with "this saying" you refer to the recent attack at Talk Talk. There were a lot of miscommunication (like talking about "sequential attack" instead of SQL injection) and part ...


9

Just type: echo root::0:0:root:/root:/bin/bash > /etc/passwd su and you are root. (Removing x means root requires no password anymore, you can use sed command instead of echo yet this is enough to get root shell)


9

Based on Matthew Garrett - Intel's remote AMT vulnerablity, which is among the most reasonable (in terms of amount of hyperbole) articles I've seen so far, you can only be affected if your system meets all four of the following criteria: A CPU supporting Active Management Technology A motherboard chipset supporting AMT Supported network hardware The ...


8

Because the context of www-data is a lot less privileged than the one of root. For instance as a root user you can alter a lot more configuration files, add or remove users, read protected folders, etc... As www-data you cannot do this, so even when exploited the attacker can only use all resources and files available to www-data. This helps contain the ...


8

You are right that you gain access to the UID of the process/script you exploited. In the case of the Apache identity with no mandatory access control and no proper separation of developer and apache roles, you can: destroy or deface the websites run by your Apache change websites' code to leak all the user database at a fixed URL that you can then consult ...


8

OK, this is not a complete answer therefore I preferred to wait for the bounty to expire to not seem opportunistic. I cannot replicate the linux-vserver part of the vulnerability (mostly because it probably needs a 2.6 kernel and the assembly above will require that both the host and the guest machines are in 32bit mode). I can only replicate the basic ...


7

This is a great question! Never thought about this until you asked. Firstly, code running inside a secure enclave runs in ring 3. So all restrictions that apply to untrusted non enclave ring 3 code apply. So an enclave cannot write to MSR's. Next, the specs don't explicitly mention anything about MSR's but it does tell you about interaction with IA32 ...


7

Yes! Binaries with a setuid bit and calling (directly or indirectly) bash through execve, popen or system are tools which may be used to activate the Shell Shock bug. If these commands aren't taking care of clearing *env prior to run bash (or a shell script) then these binaries may be used to run any command (for example bash) with the privilege of root. ...


6

These tests are run on an unpatched system: # ls='() { echo NO; }' bash -c 'ls' NO the * wildcard is required or perl will replace system call with a fork/exec combination # ls='() { echo NO; }' perl -e 'system("ls *");' NO However ls is not a builtin: # type ls ls is hashed (/bin/ls) # type echo echo is a shell builtin So lets try overriding built-in ...


5

Such setuid wrappers are dangerous regardless of whether the script interpreter is a fixed bash, an unfixed bash, or some other shell. Reason being that script interpreters are impacted by many environment variables. Oft-cited offenders are PATH and IFS. This is the reason why sudo resets the whole environment to sane values (since shell authors are ...


5

Question 0: Am I correct? Yes you are correct. Installing a package requires root privilege, so installing a malicious package means running malicious code as root. Question 2: What are the ways in which Debian team addresses this threat in the main repositories? First, you are recommended to use only Debian repository, and more precisely Debian stable ...


Only top voted, non community-wiki answers of a minimum length are eligible