[HN Gopher] Flipping Pages: New Linux vulnerability in nf_tables...
___________________________________________________________________
Flipping Pages: New Linux vulnerability in nf_tables and
exploitation techniques
Author : Unroll0201
Score : 328 points
Date : 2024-03-26 14:35 UTC (8 hours ago)
(HTM) web link (pwning.tech)
(TXT) w3m dump (pwning.tech)
| Unroll0201 wrote:
| Today I published a proof-of-concept exploit for CVE-2024-1086,
| working on Debian and Ubuntu among others.
|
| The affected exploit versions are from Linux kernel v5.14 up to
| v6.6. The support for v6.4 to v6.6 is depending on the
| `CONFIG_INIT_ON_ALLOC_DEFAULT_ON` kernel config variable, but
| please check README.md for this info.
|
| The bug was patched in February 2024, and has been labelled
| CVE-2024-1086.
|
| Make sure to update your Linux devices!
| pelagicAustral wrote:
| Awwww Fuck me! that's my lazy afternoon gone now
| richardwhiuk wrote:
| This is local privilege escalation only right?
| Unroll0201 wrote:
| Correct, but it is definitively worth updating for on high-
| profile systems.
|
| I have not tested it, but because I have included the
| namespace escape in the exploit for KernelCTF, it may be
| able to break out of LXC containers and privileged Docker
| containers running on vulnerable Linux kernels.
| dathinab wrote:
| if it works for LXC containers shouldn't it also work for
| unprivileged (but non VM) docker containers?
| Unroll0201 wrote:
| This is an educated guess, but I believe unprivileged
| Docker containers cannot create (user) namespaces. Hence,
| the vulnerability cannot be triggered, since the exploit
| requires interaction with nf_tables, which requires
| (namespace) root.
|
| LXC containers and privileged Docker containers allow
| these namespaces to be made inside of them, whilst
| unprivileged Docker containers do not.
| eikenberry wrote:
| Fixed kernel was released to Debian stable well over a month
| ago (my logs have it installed on 2/12). So unless you ignore
| kernel security updates you should already be covered.
| derelicta wrote:
| Congrats! Impressive work!
| junon wrote:
| Haha. Nice sources. And nice work, curious what the larger
| response to this will be.
|
| https://github.com/Notselwyn/CVE-2024-1086/blob/main/src/mai...
| greggsy wrote:
| What are some potential attack vectors and impacts for this
| one?
| Unroll0201 wrote:
| The attack vectors are pretty much the same for other Linux
| kernel LPE exploits. The impact is also much alike: privilege
| escalation from unprivileged user to root user. Should be
| noted that the exploit can read/write any physical memory on
| the device, but uses it to become root user.
|
| An important note is that the exploit requires nf_tables to
| be present, and unprivileged user namespaces. This can be
| checked with commands specified in the README.md file in the
| repo.
|
| Notice however that the exploit contains a namespace escape,
| allowing it to break out of namespaces on vulnerable kernels.
| As said in the other comment, this possibly includes LXC
| containers and privileged Docker containers, but this is not
| tested and is purely an educated guess).
|
| The namespace escape is included because it is a requirement
| for the KernelCTF program.
| MrStonedOne wrote:
| Attack vector requires local execution access and allows for
| escaping limited privileges like non-root user accounts and
| breaking out of (some?) namespace jails used by containers
| and sandboxing systems.
| dev_snd wrote:
| Great work and great write-up! I especially love the MAINFRAME
| BREACH PROTOCOL that comes with it.
| yjftsjthsd-h wrote:
| > The affected exploit versions are from Linux kernel v5.14 up
| to v6.4.
|
| Linked page says
|
| > The exploit affects versions from (including) v5.14 to
| (including) v6.6, excluding patched branches v5.15.149>,
| v6.1.76>, v6.6.15>.
|
| ?
| Unroll0201 wrote:
| The exploit support from v6.4 - v6.6 is depending on a Linux
| kernel kconfig value. If `CONFIG_INIT_ON_ALLOC_DEFAULT_ON` is
| set to `y`, the exploit is not working. If it is set to `n`,
| it does work. I have updated my comment.
| cedws wrote:
| Can I ask why you decided to disclose this exploit rather than
| sell it to a company like Zerodium? Is it a matter of ethics,
| or is the money not worth it for you?
| junaru wrote:
| > Zerodium customers are government institutions (mainly from
| Europe and North America) in need of advanced zero-day
| exploits and cybersecurity capabilities.
|
| How does this even openly exist in post Stuxnet world? If
| this is not clear evidence of government working with
| criminals i don't know what is.
| streb-lo wrote:
| >clear evidence
|
| evidence is not what someone writes on their landing page
| londons_explore wrote:
| Governments only _say_ they don 't work with criminals.
| redundantly wrote:
| Government officials are often criminals themselves.
| Unroll0201 wrote:
| For me it is about the ethics among other things. I do not
| know to which goverments Zerodium is selling, much like any
| other zeroday broker. Additionally, I wouldn't be surprised
| if selling to Zerodium is illegal to begin with.
|
| By taking the KernelCTF approach I get my bounty, I don't get
| into legal trouble, and I get to contribute to the Linux
| kernel VR community which means a lot to me
| caskstrength wrote:
| You are being downvoted, but as an outside observer I have
| also always been interested in ethics of security research.
| rfoo wrote:
| Good job writing this up!
|
| Quick question: for "post"-exploitation, once you had a KSMA-
| like primitive why would you choose to still do the
| modprobe_path dance, and introduce a pid bruteforce for
| fileless :(, instead of e.g. patching kernel .text with a short
| shellcode to become root & break out of namespaces?
| amne wrote:
| Dodged it!
|
| 5.10.184-175.749.amzn2.x86_64 #1 SMP
| mtlynch wrote:
| It looks like this repo is redistributing source from third-party
| libraries without required license notices.[0]
|
| You should put the license notices at the root of your ./include
| directories to respect the work of the libraries you're using.
|
| [0] https://github.com/Notselwyn/CVE-2024-1086/issues/1
| Unroll0201 wrote:
| Thanks for the notice. I will immediately fix it.
| JonChesterfield wrote:
| Summary is netfilter has a use-after-free bug and that's
| sufficient to go from a normal shell to root. Bad times, nice
| demo
| okl wrote:
| Commit which introduced the problem:
| https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
|
| The nested switch/case with return in the default path, then
| expecting fall-through, looks bogus to me.
| rightbyte wrote:
| Same guy?
|
| https://lwn.net/Articles/882397/
| pphysch wrote:
| > I would encourage you to read up on details of McHardy's
| practices. They were clearly not done in good faith and there
| was no attempt to encourage compliance. The only goal was to
| extract as much money as possible even if the violations were
| more technical or incidental in nature and the companies
| willing to attempt remedy. Even minor and unintentional
| violations were pursued zealously without interest in remedy
| - just cash.
|
| > My understanding is he also didn't truly prioritize deep
| pocketed violators (no suit against VMWare, afaik) - he
| prioritized that delicious sweet spot of "deep enough to pay
| me off, but too small to make it realistic to fight me in
| court". And, again, he was uninterested in remediation of
| even minor and unintentional violations - he wanted cash. It
| seems unlikely this was helping the cause of free software.
|
| Seems entirely possible that such a character would knowingly
| insert a backdoor to sell as a 0-day.
| spr-alex wrote:
| this code was written before unprivileged network
| namespaces were much of a thing so the theory that a
| developer would plant a bugdoor for this is not probable.
|
| you can think of unprivileged namespaces in general as a
| bunch of attack surface that was previously root to kernel
| only and hadn't had much scrutiny. these bugs will take
| decades to eliminate without a rewrite of linux.
| MuffinFlavored wrote:
| Your link converted to GitHub:
| https://github.com/torvalds/linux/commit/f342de4e2f33e0e3916...
|
| https://bugs.launchpad.net/bugs/cve/2024-1086
|
| > A use-after-free vulnerability in the Linux kernel's
| netfilter: nf_tables component can be exploited to achieve
| local privilege escalation. The nft_verdict_init() function
| allows positive values as drop error within the hook verdict,
| and hence the nf_hook_slow() function can cause a double free
| vulnerability when NF_DROP is issued with a drop error which
| resembles NF_ACCEPT. We recommend upgrading past commit
| f342de4e2f33e0e39165d8639387aa6c19dff660.
| cschmid wrote:
| For anyone who's wondering, you can see your current kernel
| config in a file like /boot/config or /proc/config.gz
| yjftsjthsd-h wrote:
| I think it's misleading to label this "Debian/Ubuntu privilege
| escalation"; it's a Linux kernel local exploit, that _happens_ to
| be confirmed to apply to Debian and Ubuntu.
|
| (Edit: Because when I read "Debian/Ubuntu privilege escalation
| PoC exploit for CVE-2024-1086" my first thought was something
| like, "Oh, is it in apt-get? Or is this another distro patch gone
| wrong?")
| wiredfool wrote:
| Also, it's already been patched and the vulnerable are the ones
| who haven't updated.
| krylon wrote:
| Thanks for pointing that out, I was confused about that.
| pajko wrote:
| The world was given a pretty short time frame to adapt. Now
| the script kiddies will unleash the hell.
| eikenberry wrote:
| It was patched a month and a half ago which means it was
| known about before that. So around 30ish days known until
| the CVE and 60 until this published exploit. IMO this is a
| decent time frame, how long do you think is enough?
| freedomben wrote:
| You're not necessarily wrong, although simply saying "Linux"
| isn't accurate either because it's in part a vuln exposed by a
| specific kconfig, which differs by distro. From the caveats
| section:
|
| > The exploit does not work v6.4> kernels with kconfig
| CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y (including Ubuntu v6.5)
|
| > The exploits requires user namespaces (kconfig
| CONFIG_USER_NS=y), that those user namespaces are unprivileged
| (sh command sysctl kernel.unprivileged_userns_clone = 1), and
| that nf_tables is enabled (kconfig CONFIG_NF_TABLES=y). By
| default, these are all enabled on Debian, Ubuntu, and
| KernelCTF. Other distro's have not been tested, but may work as
| well.
|
| Also with other distros like Fedora and Arch, the kernel
| versions change frequently including new big versions (like 6.4
| to 6.5, what in semver would be called "minor" but isn't super
| accurate for the linux kernel) so that list would be outdated
| very quickly if not immediately (for example my Fedora machine
| right now is on kernel 6.7.9, way beyond what is vulnerable).
| It's quite possible that Ubuntu _is_ the only vulnerable distro
| given the way they manage kernel versions. That 's not a
| criticism of Ubuntu, because there are pros and cons of each
| approach, but in _this_ case it does probably make Ubuntu more
| vulnerable. RHEL and derivatives also tend to stick on a
| version long term, and it looks like RHEL 9.3 is on kernel 5.14
| so _could_ be vulnerable but it 's at the very beginning of the
| range. That would be a useful thing to know.
|
| I think it's also (generally) far more useful for most people
| to hear a descriptor that most closely aligns with something
| they can readily identify whether it affects them or not. Then
| people can look at the details themselves.
|
| Edit: added a little more on other distros like Fedora and Arch
| candiddevmike wrote:
| Interesting Arch discussion on the security implications of
| user namespaces when they were considering adding it to their
| kconfig: https://bugs.archlinux.org/task/36969
| yjftsjthsd-h wrote:
| > simply saying "Linux" isn't accurate either because it's in
| part a vuln exposed by a specific kconfig, which differs by
| distro
|
| True; if the Debian family is unusual in having that config
| then fair enough, but it sounds like the author just didn't
| look at others.
|
| > Also with other distros like Fedora and Arch, the kernel
| versions change frequently including new big versions (like
| 6.4 to 6.5, what in semver would be called "minor" but isn't
| super accurate for the linux kernel) so that list would be
| outdated very quickly if not immediately
|
| Debian/Ubuntu still roll patch releases regularly, so that
| seems irrelevant; it'll be out of date in short order
| regardless.
| dang wrote:
| We've changed the title from "Debian/Ubuntu privilege
| escalation PoC exploit for CVE-2024-1086" as part of changing
| the URL (see https://news.ycombinator.com/item?id=39830200)
| rakejake wrote:
| Running Ubuntu with Kernel 6.5.0-26 Got this?
|
| failed to detect overwritten pte: is more PTE spray needed? pmd:
| 00000000cafebabe
| Unroll0201 wrote:
| This is indeed expected. I specified in the "Caveats" section
| in README.md that the exploit does not work on Ubuntu v6.5
| (because it enables a certain kernel config value that
| indirectly mitigates the exploit starting from v6.4), and may
| not work on other kernels above v6.4 depending on the config.
| rakejake wrote:
| Ah I read that versions upto v6.6 were affected and didn't
| notice the caveats. Thanks
| loudmax wrote:
| This exploit relies on unprivileged access to user namespaces:
| `sysctl kernel.unprivileged_userns_clone = 1`
|
| This is the default setting for Debian/Ubuntu, and also Arch
| Linux kernels. If you don't have a need for that setting, (eg.
| running Docker commands without sudo), you should probably
| disable that anyway.
| yjftsjthsd-h wrote:
| :\ It really is unfortunate that that setting is _great_ for
| letting people run containers (and the like) without giving
| them root access... but also has a bad track record of then
| having vulnerabilities that allow root access.
| dathinab wrote:
| IMHO it is just too complicated/flexible designed.
| yjftsjthsd-h wrote:
| I'm not a kernel developer so take with a grain of salt;
| what I've _heard_ suggested is that it 's not fundamentally
| bad and if we'd had it from day one it would be fine, but a
| lot of kernel interfaces were designed with the idea that
| only root could use them so they didn't worry about certain
| security matters as much. And maybe that was never _ideal_
| but it could even be reasonable; if only root can trigger a
| bug that gives you root access... it 's not good because it
| could be used to work around other restrictions, but one
| can imagine that it wouldn't exactly be a priority. But
| then what actually happened is that very late in the game
| we got this new feature that allows any old user to access
| these less-protected interfaces, and that's resulted in a
| certain amount of... catching up.
| dathinab wrote:
| It's not just used by docker/packman.
|
| But also e.g. by the chrome sandbox used by e.g. electron apps
| (or e.g. 1password). Through that sandbox helper binary can
| also work with being a suid program.
|
| I also wouldn't be too surprised if e.g. proton will start
| using user namspaces at some point in the future.
|
| So for any non-hardened desktop linux system you probably
| should _not_ disable it!
|
| (For many servers or special hardened Linux it often isn't a
| bad idea to disable it.)
| aidenn0 wrote:
| 6.1.65 and that option doesn't exist. Did it get renamed?
| Unroll0201 wrote:
| The sysctl command isn't available on specific kernel
| configurations. You could try running `unshare -Urn`. If it
| runs without sudo (and you haven't configured any specific
| permissions yourself), unprivileged namespaces are enabled.
| bjackman wrote:
| I don't think it's in the upstream kernel - various distros
| carry it as a patch. Maybe yours doesn't?
| tryauuum wrote:
| why are unprivilged user namespaces enabled by default? why by
| default give user the ability to run iptables and other stuff
| (mount?) (even though it runs in an "unprivilged" namespace)
| yjftsjthsd-h wrote:
| Because if they didn't keep having bugs like this, they'd be a
| great security feature. Like, it'd be great if running flatpaks
| didn't require a suid binary on the host in order to isolate
| apps.
| _factor wrote:
| The issue is the "just works" philosophy. Most defaults are
| insecure and require technical expertise and hardening.
| kentonv wrote:
| Unprivileged user namespaces make it possible for unprivileged
| programs to set up sandboxes.
|
| For example, Chrome uses namespaces to implement its process
| sandbox. However, Chrome installs a setuid-root binary, so that
| it doesn't need "unpriveleged" namespaces enabled. This is sad,
| though: setuid-root binaries are inherently a security risk of
| their own. It would be nice if Chrome did not need to install a
| suid-root binary. But, it can only possibly avoid this in the
| future if unprivileged user namespaces are widely available.
| Bugs like this unfortunately delay that future.
|
| Incidentally, programs like Chrome that set up namespace-based
| sandbox also commonly use seccomp to prevent the sandboxed code
| from using exotic kernel features -- including namespaces. So
| user namespaces won't be available to sandboxed code regardless
| of whether you enable unprivileged user namespaces at the
| system level.
|
| Personally I feel that on a single-user desktop, there's little
| point in enforcing a separation between users and root --
| everything interesting is probably available to your user
| account anyway. But sandboxes like Chrome's are obviously
| essential to security on desktops. So I'd tend to say, on a
| single-user desktop, enabling unprivileged user namespaces
| improves security overall, by encouraging the use of sandboxes.
|
| Multi-user systems are a different story, obviously.
| dathinab wrote:
| Chromes sandbox uses unprivileged namespaces but has a suid-
| root fallback.
|
| Electron apps too (if sandboxing is enabled).
|
| Bubblewrap (used by flatpack, idk. about snap) prefers user
| namespaces, too.
|
| All of them could can have suid fallbacks they would prefer
| to not have.
|
| Tbh. if Linux had a proper capability system it probably
| would make sense to attach a "user ns" capability to binaries
| which in the past used suid-root for namespaces and not allow
| "other" processes to use it.
|
| > there's little point in enforcing a separation between
| users and root
|
| I don't agree. But it is a different discussion. (And a
| complicated discussion too as Linux desktop is IMHO currently
| lacking in various security areas as security requirements
| have changed. So often when you argue they should do this you
| get non productive answers like "oh but you also could do
| [that other think which also need to change sooner or
| later]". Anyway it can make the difference between it being
| easily able to steal all password from your password manager
| and it only being able to steal the passwords you did use
| since infection. Or it being able to steel a early boot full
| disk encryption key. etc. etc.)
| IshKebab wrote:
| > there's little point in enforcing a separation between
| users and root
|
| I agree but I don't think that's fundamental. It's pointless
| on Linux because any attacker can simply alias `sudo` to
| something and wait.
|
| But I can imagine a modern desktop OS where there's a useful
| admin account. Windows is pretty close. Much better than
| Linux on that front.
| PlutoIsAPlanet wrote:
| Even on a Linux desktop OS with a single user, it's still a
| security risk as it skips over a last line of defence.
|
| If a Chrome bug is found that allows web pages to arbitrary
| code execution, it can be chained with an exploit like this
| to infect more than just the user account, potentially,
| depending on the computer, the firmware itself.
| IshKebab wrote:
| Sure but most malware doesn't really care about infecting
| more than the user. The only reason to infect firmware is
| to gain persistence in the face of OS reinstalls, but
| those are very rare in general. Only targeted NSA level
| malware is going to bother with that.
|
| For normal botnet/cryptocurrency stealing malware once it
| has user access it has everything it needs.
| kentonv wrote:
| Yes, I agree. But I don't think the path forward is to re-
| establish the security of root. Instead the path forward is
| to stop granting the full capabilities of the user to every
| program the user runs. In Android, for example, every app
| has its own user account. That is meaningful! I wish every
| desktop app were sandboxed by default, but it requires
| redesigning so many interfaces that you might as well think
| of it as a whole new platform.
|
| Of course, such a platform basically exists: the web
| platform.
|
| I think everything-is-a-web-site is the realistic way we
| get to secure desktops. I don't like it but it's hard to
| imagine anything else getting traction from here.
| jiripospisil wrote:
| Is there a reason why user namespaces cannot be enabled per
| executable? setcap "something something user ns"
| /usr/bin/chrome?
| kentonv wrote:
| In theory that might work. In practice, it doesn't help
| much; you might as well stick with setuid-root.
|
| * The mechanism for granting capabilities to binaries is
| convoluted, requiring special tools, filesystem support,
| and fiddly code. It's surprisingly tedious to make it work.
|
| * There's no specific capability for user namespaces. When
| they require privileges at all, they require CAP_SYS_ADMIN.
| This capability is basically equivalent to root anyway. In
| fact, many Linux capabilities can easily be escalated to
| full root privileges.
|
| My personal opinion is that Linux "capabilities" are not
| worth using most of the time. (I also hate that they are
| called "capabilities", a word that I would rather reserve
| for object-capabilities, which are an actually-useful
| security model!)
| wiredfool wrote:
| According to ubuntu -- It hits all LTS releases, and is fixed in
| current patched kernels:
| (https://ubuntu.com/security/CVE-2024-1086) *
| Focal: 5.4.0-174.193 * Jammy: 5.15.0-101.111 *
| Mantic: 6.5.0-26.26
|
| As well as Xenial and Bionic for those of you with extended
| support
| whoopdedo wrote:
| Does this still work if you have user namespace covered by
| AppArmor?
|
| https://discourse.ubuntu.com/t/spec-unprivileged-user-namesp...
| bhaney wrote:
| Tried running it on a vulnerable Debian system of mine. Didn't
| privesc, but did lock up the entire system on the second run
| (first run just failed entirely). So still definitely worth
| taking the time to patch.
| pqdbr wrote:
| How do I check if my Ubuntu kernel has already been patched?
|
| And if it hasn't, any tips on how to upgrade?
| popol12 wrote:
| sudo apt-get install musl-tools
|
| git clone https://github.com/Notselwyn/CVE-2024-1086
|
| cd CVE-2024-1086
|
| / _disable your wifi (the author says it 's increasing chances
| of the exploit working)_/
|
| ./exploit
|
| If it runs till the end, then you should update your kernel
| caseyf wrote:
| little warning for others - i tested it on a jammy box with
| kernel.unprivileged_userns_clone = 0 and it froze up good
| wiredfool wrote:
| https://ubuntu.com/security/CVE-2024-1086
|
| There's a super long list there, but most everything has been
| updated or superceded.
|
| The standard (updated) kernels are: * Focal:
| 5.4.0-174.193 * Jammy: 5.15.0-101.111 * Mantic:
| 6.5.0-26.26
|
| And if you haven't updated, apt-get update && apt-get dist-
| upgrade.
| andy_xor_andrew wrote:
| I have some questions for you wizard shellcode-flinging hackers
| out there.
|
| with modern mitigations like ASLR and beyond, how are exploits
| like this even possible?
|
| I took a course in college which provided us with a dozen
| binaries, to be run on a specific Ubuntu version. Each binary had
| a different bug, use-after-free, buffer overflow, both, or more,
| and our task was to exploit it.[0]
|
| It was HARD. Finding the flaw was hard. Then, writing the exact
| correct shellcode to do something useful with the flaw was even
| harder. Especially when you only have the compiled binary and GDB
| to work with.
|
| In harder levels, we had to do this with mitigations enabled like
| ASLR, stack canaries, etc.
|
| And my takeaway was, this is nearly impossible, because you need
| to 1. discover an exploitable flaw (or multiple, and chain them
| together!!) 2. find the exact binary shellcode payload that will
| do something useful without simply crashing the executable. And
| this was in a controlled environment as students, not the real
| world which is even more difficult.
|
| So my question is, with all these mitigations, how is it
| possible?!
|
| [0] I googled for the exact project but could not find it, though
| it was very very similar to this:
| https://web.stanford.edu/class/archive/cs/cs107/cs107.1194/a...
| 4gotunameagain wrote:
| There's an entire section about KASLR in the blogpost linked on
| the repository.
| freedomben wrote:
| short answer: some people are good, some people are lucky, and
| some people are good _and_ lucky. It only takes one from the
| latter category to find these things
|
| longer answer: It is definitely really damn hard these days.
| Even disabling the mitigations, it's still pretty hard to find
| and a vuln and write an exploit. But many people who find these
| (not all though) work as part of a team, where they can
| parallelize fuzzing efforts and combine/chain knowledge and
| other exploits much better than an individual could. The level
| of expertise and talent that some of these people have is
| absolutely incredible, and experience is worth a pound of gold
| for these types of things, and some people have years or
| decades of experience.
| jimmyl02 wrote:
| modern mitigations have made exploits much more difficult,
| however researchers continue to find bypasses to these
| mitigations.
|
| there are "classic" techniques to bypass most of the modern
| protections and if there isn't then researchers often come up
| with novel attacks / bypasses. for example for heap protections
| you can see how2heap to bypass heap protections[0]. another
| example is an exploit which allows bypass of KASLR (which has
| since been patched)[1]. it looks like this exploit comes up
| with a "dirty pagetable" technique[2].
|
| it's always a game of cat and mouse with more mitigations
| always being added while researchers constantly look to bypass
| them.
|
| [0] https://github.com/shellphish/how2heap
|
| [1] https://www.willsroot.io/2022/12/entrybleed.html
|
| [2] https://pwning.tech/nftables/#452-the-technique
| Veserv wrote:
| You were a inexperienced beginner finding and exploiting tens
| of bugs over a 10-15 week course. In between other courses and
| learning you only had hours to maybe a few days per bug. On
| Zerodium [1], a generic Linux LPE pays 50 K$. At normal
| experienced exploit developer costs that buys you ~200 person-
| hours. That is professionals spending 10-100x as much time as
| you spent.
|
| Just think of the gap between the first time in the woodworking
| shop and a carpenter, first time pottery versus a master, a new
| painter and a professional artist. Think of how many things the
| master can do that it is literally impossible for the new
| person to do. Then add another 10-100x as much time on that.
| That is the gap.
|
| [1] https://zerodium.com/program.html
| rfoo wrote:
| It makes your point even stronger, but
|
| > a generic Linux LPE pays 50 K$. At normal experienced
| exploit developer costs that buys you ~200 person-hours.
|
| $250 per hour? I must be living in the wrong part of the
| world then, where can find an exploit developer job like this
| :o
| bawolff wrote:
| I don't work in that space, so i don't know what is normal,
| but that sounds reasonable to me. Its a niche field that
| requires quite a bit of low level skill. I'd expect it to
| pay significantly more than web dev jobs
| Veserv wrote:
| Costs, not salary. Overhead is usually 1.5x-3x salary and I
| was throwing in some profit for good measure. So the number
| I threw out is more in the 150 k$-300 k$ range, not the 500
| k$ range like you are thinking.
| robotnikman wrote:
| I've wondered this myself. I've tried a class similar to yours,
| where you were provided with binaries and tried to find the
| bugs in them. And it was hard.
|
| But when you consider that major bugs found now are being found
| by well funded teams or state actors trying to exploit them, it
| makes more sense that they would be able to work around
| existing mitigations due to the sheer manpower and resources
| they have to throw at the problem.
| dang wrote:
| Url changed from https://github.com/Notselwyn/CVE-2024-1086,
| which points to this.
| Unroll0201 wrote:
| Is there a reason why you did this? I knowingly chose the other
| title because it would apply more to the Hackernews audience to
| raise more awareness of the exploit and that people should
| update. This title was aimed at the Linux kernel VR community,
| which also shows because the post instantly dropped down from a
| 2-hour #1 position to #8
| dang wrote:
| The title generated complaints:
| https://news.ycombinator.com/item?id=39829308. In such cases
| we usually change the title (experience has shown this to be
| the best way to turn discussion away from title complaints to
| whatever the more interesting topic is). In doing that, I
| noticed that the blog post includes a lot more background
| than the github link, so I switched the URL as well.
| freedomben wrote:
| This is an extremely impressive write-up.
|
| When writing security blog posts, there's always a constant
| battle of essentially "how much background/prerequisite knowledge
| do I assume," and getting the balance right to make it accessible
| but also feasible to write can be very challenging. Identifying
| your target market up front, and then delivering to that market
| with plenty of background info, is no easy feat! Well done!
|
| I'm bookmarking this to give to aspiring researchers, of whom I
| meet a few every year who are looking for guidance like this.
| Unroll0201 wrote:
| Thank you so much! It feels great to hear this.
| bakkoting wrote:
| From the patch [1]:
|
| > This reverts commit e0abdadcc6e1. [...] Its not clear to me why
| this commit was made.
|
| Anyone dug up the history here?
|
| [1]
| https://lore.kernel.org/all/20240120215012.129529-1-fw@strle...
| tg180 wrote:
| https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
|
| > netfilter: nf_tables: accept QUEUE/DROP verdict parameters
|
| > Allow userspace to specify the queue number or the errno code
| for QUEUE and DROP verdicts.
| loeg wrote:
| Yeah, but _why?_
| rokkitmensch wrote:
| If one has to ask, it's a Five Eyes plant.
| aseipp wrote:
| Hardly. This is just a typical double free vulnerability,
| AKA a normal Tuesday in the C/C++ world, and which people
| have been exploiting in the kernel (with its complex
| object lifetimes and semantics) for well over 10 years
| now. There's no need to "plant" anything to find these.
| aseipp wrote:
| The original commit is over 10 years old now, so it's probably
| lost to the sands of time. I did some looking but couldn't find
| anything on the old netdev lists. Maybe the patch was sent
| directly to Pablo Neira Ayuso, the committer. It was part of a
| series so it's not like it was a one-off patch.
|
| In a strange twist of fate, the original author was Patrick
| McHardy who is now a persona non grata. Unless Pablo can
| remember or dig it from his emails, it probably won't ever be
| clear exactly what the use case was, at least not through basic
| investigation.
| jcalvinowens wrote:
| Distros don't build with it, but CONFIG_INIT_ON_FREE_DEFAULT_ON
| prevents the exploit. I think it's a nice demonstration of the
| value of the hardening in the kernel.
| FergusArgyll wrote:
| I just tried this on WSL Ubuntu (after an apt update && upgrade),
| Completely freaked my computer out, I almost thought I bricked it
| but a restart worked.
|
| I'm not smart enough to understand it but someone may want to
| look into it
| mise_en_place wrote:
| Oof, double free is one of those notorious bugs. And to think it
| comes from something as innocuous as netfilter rules.
___________________________________________________________________
(page generated 2024-03-26 23:00 UTC)