Bottom line - locally exploitable vulnerability in the linux kernel, in case you have the CAP_NET_RAW capability which never really happens. Not a real security threat for your standard linux distro.
On the other hand, this is a great technical write-up that describes thoroughly the internals of some of the linux kernel subsystems. Probably the best documentation you can find for some subsystems. Also shows how they bypassed exploit mitigations technics such as KASLR, SMAP&SMEP.
Right, but "unprivileged user namespaces" are disabled in many contexts, because they've been a source of many vulnerabilities due to code originally thought to only be reachable by root anyway.
Archlinux has user namespaces disabled, docker does not use them by default and does not allow them inside containers by default, on Ubuntu I make sure to disable kernel.unprivileged_userns_clone on all the servers I deploy to, etc.
No. It's exploitable by a normal unprivileged user on modern Ubuntu. From the article, "Let’s see how we can exploit this vulnerability. I’m going to be targeting x86-64 Ubuntu 16.04.2 with 4.8.0-41-generic kernel version with KASLR, SMEP and SMAP enabled. Ubuntu kernel has user namespaces available to unprivileged users (CONFIG_USER_NS=y and no restrictions on it’s usage), so the bug can be exploited to gain root privileges by an unprivileged user."
As a rule of Thumb, an attack can ALWAYS escape from Docker containers.
These containers are a light way to separate processes. They are not intended as a security measure to isolate malicious processes that tries to escape.
No, Docker usually drops CAP_NET_RAW within the container. But you can change that and other container technologies definitely keep CAP_NET_RAW within the container.
You also need to create a network namespace, because to create an AF_PACKET socket you need to have CAP_NET_RAW in the user namespace that owns your network namespace, not the user namespace you're in.
Great read as usual. They are doing a big service to the people out there by hunting bugs like this one and putting the pressure on the vendors to fix their products.
This is a locally exploitable privilege escalation involving creation of the socket, triggerable from user level, so exploitable by local users or as a followup after another exploit is used to get some level of local access, correct?
Not really. Requires to have the CAP_NET_RAW capability, which is pretty rare. (This capability allows you raw access to the network interface, which is usually only given to the root user)
No. It's exploitable by a normal unprivileged user on modern Ubuntu. From the article, "Let’s see how we can exploit this vulnerability. I’m going to be targeting x86-64 Ubuntu 16.04.2 with 4.8.0-41-generic kernel version with KASLR, SMEP and SMAP enabled. Ubuntu kernel has user namespaces available to unprivileged users (CONFIG_USER_NS=y and no restrictions on it’s usage), so the bug can be exploited to gain root privileges by an unprivileged user."
Thanks, I was a bit concerned at first when I saw the 4 words "Exploiting Linux kernel packet" on one line, but as a privilege escalation after a first exploit I won't worry as much about it.
It's just domain knowledge and terminology. "Packet sockets" is shorthand for the AF_PACKET type sockets in Linux that let you construct network packets from the ground up, including the ethernet header, if you so wish.
That's as opposed to a regular socket, which is higher level and restricts you to a much smaller subset of things you can change/set.
The article just shows how they uncovered an exploit by "fuzzing" input to packet sockets. Where "fuzzing" just means using a tool that creates random inputs/values.
The concept I think I can still get my head around. It's all the stuff that surrounds it that eludes me. I have done some work in C but that C is unlike any of the C I wrote in college (duh, it's the kernel code)
I don't see what you mean. It's a long line, so it breaks across 3 lines, but otherwise, it's just:
if (a >= b && (int)(c - MACRO(d)) <= 0) goto out;
Or the stuff further down? Just confusing because tpacket_req and friends are defined as structs elsewhere, so you don't have that context. And it's not really C, it's syzkaller (fuzzing tool) descriptions, kind of a pseudo code syntax.
Webapps use some of the highest-level tools, quite abstracted from most actual hardware.
This does not make webapps necessarily simple: complex UI logic, asynchronous everything often constant two-way communication with a server, maybe with conflict resolution, etc.
I believe that the serial device /dev/ttyS0 was named in honor of Theodore Ts'o. So maybe tpacket could be at least retroactively declared to honor tptacek.
But isn't embedded programming more complex? as in, it requires a well founded understanding of CS concepts, as well as requires advanced ability in programming and math.
I imagine to an embedded developer, the web just looks like madness because there's no consistency. Parachute into a web app you've never seen before, one that might not have been developed well.
Your task is to make a button that's currently green and make it blue instead. What's the right file(s) to edit? How many layers of caching do you need to disable to see that your change actually worked? Do you need to restart anything after the change for it to be seen?
The current green color could be:
- in a css file, but one that has to go through SAAS/LESS first, or maybe not. Or maybe there's more than one entry, depending on @media screen resolution? Or maybe it's not a file at all...the css "file" is generated on the fly by some server-side framework.
- in an html file, but in <style> tags. Or maybe dynamically generated style tags via client side javascript. Or maybe server-side dynamically generated style tags? Or maybe not style tags at all? Perhaps a style attribute on the button.
- Or hey, that looks like a button, but it's not a button at all. It's an <a> tag with button styling. And it's green, but only because of a background image. Which is loaded how (static css? dynamic js style manipulation? inline <img> tag in the <a>? something else?)
Having done a bit of embedded work (I have quite a few esp8266 and esp32 dev boards programmed primarily with C and some using micropython), but also doomg a decent bit of webdev, although more server side backend than actual pure is front end...
You sir win the Internet for today.
Besides a much steeper learning curve to C, it is much easier. If you put the GPIO pull-up to high, the LED turns on. If you put it to low, the LED turns off. It is much simpler in that there isn't much abstraction really at all.
Not really. You can do a lot of embedded programming in C or Python or JavaScript or even Lua. You just need to be willing to not learn the next hot new framework and instead learn how the hardware underneath works. Checkout say a NodeCMU esp8266 with either JavaScript or Lua. It is a 32 bit tensillica CPU, and it is easy to learn. I didn't go to college for CS and have programmed dozens and dozens of them for fun and various IoS (internet of shit) sensors and relays.
Instead of spending ~100 for a MyQ smart garage opener I spent less than 20 for an Adafruit Huzzah and some sensors. Then I taught myself to program it and boom. It isn't hard if you're dedicated and have a project to learn with a clear bend goal.
I'd agree with advanced ability in programming - especially understanding things like concurrency - but probably not so much with advanced ability in maths.
On the other hand, this is a great technical write-up that describes thoroughly the internals of some of the linux kernel subsystems. Probably the best documentation you can find for some subsystems. Also shows how they bypassed exploit mitigations technics such as KASLR, SMAP&SMEP.