6 ms·

So if i unerstand correctly - its 4 second proof of work, and there is a payout once a month. Are there really so many exploits that people are racing to get i

So if i unerstand correctly - its 4 second proof of work, and there is a payout once a month. Are there really so many exploits that people are racing to get it every month?

philodeon 1y ago
Yes, the myth of Linux kernel security is just that, a myth.
- api 1y ago
  But we don’t need safe languages.
- jeffbee 1y ago
  How does this myth even exist? There has never been a moment in the history of Linux where it lacked an exploitable flaw. The only uncertainty is that for the last couple of days we aren't sure exactly what the exploit is.
  - landr0id 1y ago
    A myth propelled by people who don't understand security continually saying "Anyone can read the code, therefore it's more secure".
    - mmsc 1y ago
      b-b-but, my linux distribution is perfect for multi-tenant/multi-user purposes!!
      - udev4096 1y ago
        Most of the serious security researchers, such as Daniel Micay (lead developer of GrapheneOS), have been quite vocal [0] on how insecure linux is. [0] - https://old.reddit.com/r/GrapheneOS/comments/bddq5u/os_security_ios_vs_grapheneos_vs_stock_android/ekzo6c0/?context=3#ekzo6c0 https://old.reddit.com/r/GrapheneOS/comments/bddq5u/os_secur...
        spookie 1y ago
        I would really like for him to go into detail into why Flatpak is flawed from day one, or his MAC criticisms. Fedora has a lot done on the former and no mention of it. Also why not recognize the strides Wayland made for security in the desktop? Very handwavey take.
        jorvi 1y ago
        It's pretty ironic that he first laudes macOS so much, disparages Linux for having strong NIH, but then hates on systemd which is heavily heavily inspired on macOS. And yeah, I don't understand his hate on Flatpak unless he means the sandbox is too user-hostile. So many things break with Flatpaks, from native messaging hosts (think browser extension talking to desktop application) to theming to local folder access to pasting from the buffer.. it's quite a draconian sandbox.
        fucker42069 1y ago
        [dead]
  - aidenn0 1y ago
    This exists because: 1. When Linux was "coming of age" (around the turn of the millennium), Windows security was really bad. 2. At the same time, there were far more Windows machines than Linux 3. #1 and #2 together made Windows such an attractive target, that exploits for Linux were less of a thing.
    - rhet0rica 1y ago
      Don't forget: 4. Poor binary compatibility made it seem like worms were impossible, and twenty years ago, the most dangerous cyberattacks were 'pranks' designed to hose as many PCs as possible
      - whizzter 1y ago
        In Linux? No, C/C++-compiled binaries with dynamic linking often had issues due to glibc versions diffing,etc but you could always compiled things statically. "not ok" by LGPL licence so an issue for games,etc that wanted closed source so people talked about it, but a malicious worm creator could definitely go there since they probably wouldn't care about (L)GPL compliance (remember Linus has always been very hard on patches not breaking userspace ABI's).
        rhet0rica 1y ago
        Yeah. Emphasis on the "seem" part. A false sense of security brought on by, "If binary artifacts for package _foo_ can't be ported between distros, what chance do worms have?" plus the even older memory that the Morris worm had been designed around (and limited to) certain target platforms and architectures: https://en.wikipedia.org/wiki/Morris_worm https://en.wikipedia.org/wiki/Morris_worm
        bobmcnamara 1y ago
        > dynamic linking often had issues due to glibc versions diffing This was annoying for exploit authors as well. Like an early form of ASLR.
    - rfoo 1y ago
  - thephyber 1y ago
    The myth has some truth to it. The impact of the average Windows exploit was higher than the average Linux exploit because non-NT Windows didn’t use best practices such as multiple accounts + least privilege. And for years there were daemons on Windows that would get exploited with RCE just idling on a network (eg. Conficker). It took Microsoft several years of being a laughing stock of security before Bill Gates made the decision to slow new feature development while the company prioritized security. Windows security then increased. I believe that was around the time that Microsoft started reusing the NT kernel in the consumer versions of Windows. Also, the myth ignores the fact that cybersecurity risk has components of likelihood (a percentage) and impact (an absolute number, sometimes a dollar value). This conflation of two components invites lots of arguments and confusion, as commonly seen when certain CVEs are assigned non-obvious CVS scores.
    - bonzini 1y ago
      > around the time that Microsoft started reusing the NT kernel in the consumer versions of Windows. Much later. Windows XP used the NT kernel in 2001, whereas Conficker was in 2008.
      - aidenn0 1y ago
        I had a copy of an XP service-pack burned to a CD because an unpatched install in the dorms at college would be infected by a worm (maybe Nimda?) faster than you could download the patches, thus requiring a fully offline install.
- JackSlateur 1y ago
  Is it, tho ? The ratio bug/feature is what matter (systems with no bugs but no features are nice but we have work to do)
dist-epoch 1y ago
These are local escalation of privilege exploits (becoming root from a regular user), not remote code execution. Escalation of privilege bugs are a dime a dozen.
- internetter 1y ago
  It wouldn't be reasonable to expect it to be a RCE bug. That wouldn't be a kernel bug, it would be in the networking stack or software running.
  - eptcyka 1y ago
    Where is the networking stack running on a typical Linux deployment? (:
    - internetter 1y ago
      Yes, and most software runs on a host operating system. Vulnerabilities in the software of 3rd party developers aren’t in scope, even if it extends the kernel. Some networking tasks are delegated to the kernel, but almost all of the really risky stuff is not in the core kernel.
- singron 1y ago
  I think this also requires user (i.e. unprivileged) namespaces since you have to manipulate traffic control queue disciplines (tc qdisc). You normally need to be root to do this, so it's only useful as an escalation if you can do it within a namespace or you can convince some root daemon to do the qdisc manipulation for you (I think unlikely?). User namespaces opened up an enormous surface area to local privilege escalation since it made a ton of root-only APIs available to non-root users. I don't think user namespaces are available on android, and it's sometimes disabled on linux distributions, although I think more are starting to enable it. Relatedly, kernelCTF just announced they will be disabling user namespaces, which is probably a good idea if they are inundated with exploits: https://github.com/google/security-research/commit/7171625f57154db3c1a67b820d84650ece88ed2a https://github.com/google/security-research/commit/7171625f5...
Aurornis 1y ago
The server was open every 2 weeks. The proof of work was to slow down connections slightly to reduce incentives to spam as many connection requests as possible. Public CTFs are hard because inevitably some team will try something resembling a DDoS as part racing to the finish. Google removed the proof of work step after this.

So if i unerstand correctly - its 4 second proof of work, and there is a payout once a month. Are there really so many exploits that people are racing to get it every month?

philodeon 1y ago

Yes, the myth of Linux kernel security is just that, a myth.

api 1y ago
But we don’t need safe languages.
jeffbee 1y ago
How does this myth even exist? There has never been a moment in the history of Linux where it lacked an exploitable flaw. The only uncertainty is that for the last couple of days we aren't sure exactly what the exploit is.
- landr0id 1y ago
  A myth propelled by people who don't understand security continually saying "Anyone can read the code, therefore it's more secure".
  - mmsc 1y ago
    b-b-but, my linux distribution is perfect for multi-tenant/multi-user purposes!!
    - udev4096 1y ago
      Most of the serious security researchers, such as Daniel Micay (lead developer of GrapheneOS), have been quite vocal [0] on how insecure linux is. [0] - https://old.reddit.com/r/GrapheneOS/comments/bddq5u/os_security_ios_vs_grapheneos_vs_stock_android/ekzo6c0/?context=3#ekzo6c0 https://old.reddit.com/r/GrapheneOS/comments/bddq5u/os_secur...
      - spookie 1y ago
        I would really like for him to go into detail into why Flatpak is flawed from day one, or his MAC criticisms. Fedora has a lot done on the former and no mention of it. Also why not recognize the strides Wayland made for security in the desktop? Very handwavey take.
        jorvi 1y ago
        It's pretty ironic that he first laudes macOS so much, disparages Linux for having strong NIH, but then hates on systemd which is heavily heavily inspired on macOS. And yeah, I don't understand his hate on Flatpak unless he means the sandbox is too user-hostile. So many things break with Flatpaks, from native messaging hosts (think browser extension talking to desktop application) to theming to local folder access to pasting from the buffer.. it's quite a draconian sandbox.
        fucker42069 1y ago
        [dead]
- aidenn0 1y ago
  This exists because: 1. When Linux was "coming of age" (around the turn of the millennium), Windows security was really bad. 2. At the same time, there were far more Windows machines than Linux 3. #1 and #2 together made Windows such an attractive target, that exploits for Linux were less of a thing.
  - rhet0rica 1y ago
    Don't forget: 4. Poor binary compatibility made it seem like worms were impossible, and twenty years ago, the most dangerous cyberattacks were 'pranks' designed to hose as many PCs as possible
    - whizzter 1y ago
      In Linux? No, C/C++-compiled binaries with dynamic linking often had issues due to glibc versions diffing,etc but you could always compiled things statically. "not ok" by LGPL licence so an issue for games,etc that wanted closed source so people talked about it, but a malicious worm creator could definitely go there since they probably wouldn't care about (L)GPL compliance (remember Linus has always been very hard on patches not breaking userspace ABI's).
      - rhet0rica 1y ago
        Yeah. Emphasis on the "seem" part. A false sense of security brought on by, "If binary artifacts for package _foo_ can't be ported between distros, what chance do worms have?" plus the even older memory that the Morris worm had been designed around (and limited to) certain target platforms and architectures: https://en.wikipedia.org/wiki/Morris_worm https://en.wikipedia.org/wiki/Morris_worm
      - bobmcnamara 1y ago
        > dynamic linking often had issues due to glibc versions diffing This was annoying for exploit authors as well. Like an early form of ASLR.
  - rfoo 1y ago
- thephyber 1y ago
  The myth has some truth to it. The impact of the average Windows exploit was higher than the average Linux exploit because non-NT Windows didn’t use best practices such as multiple accounts + least privilege. And for years there were daemons on Windows that would get exploited with RCE just idling on a network (eg. Conficker). It took Microsoft several years of being a laughing stock of security before Bill Gates made the decision to slow new feature development while the company prioritized security. Windows security then increased. I believe that was around the time that Microsoft started reusing the NT kernel in the consumer versions of Windows. Also, the myth ignores the fact that cybersecurity risk has components of likelihood (a percentage) and impact (an absolute number, sometimes a dollar value). This conflation of two components invites lots of arguments and confusion, as commonly seen when certain CVEs are assigned non-obvious CVS scores.
  - bonzini 1y ago
    > around the time that Microsoft started reusing the NT kernel in the consumer versions of Windows. Much later. Windows XP used the NT kernel in 2001, whereas Conficker was in 2008.
    - aidenn0 1y ago
      I had a copy of an XP service-pack burned to a CD because an unpatched install in the dorms at college would be infected by a worm (maybe Nimda?) faster than you could download the patches, thus requiring a fully offline install.
JackSlateur 1y ago
Is it, tho ? The ratio bug/feature is what matter (systems with no bugs but no features are nice but we have work to do)

dist-epoch 1y ago

These are local escalation of privilege exploits (becoming root from a regular user), not remote code execution. Escalation of privilege bugs are a dime a dozen.

internetter 1y ago
It wouldn't be reasonable to expect it to be a RCE bug. That wouldn't be a kernel bug, it would be in the networking stack or software running.
- eptcyka 1y ago
  Where is the networking stack running on a typical Linux deployment? (:
  - internetter 1y ago
    Yes, and most software runs on a host operating system. Vulnerabilities in the software of 3rd party developers aren’t in scope, even if it extends the kernel. Some networking tasks are delegated to the kernel, but almost all of the really risky stuff is not in the core kernel.
singron 1y ago
I think this also requires user (i.e. unprivileged) namespaces since you have to manipulate traffic control queue disciplines (tc qdisc). You normally need to be root to do this, so it's only useful as an escalation if you can do it within a namespace or you can convince some root daemon to do the qdisc manipulation for you (I think unlikely?). User namespaces opened up an enormous surface area to local privilege escalation since it made a ton of root-only APIs available to non-root users. I don't think user namespaces are available on android, and it's sometimes disabled on linux distributions, although I think more are starting to enable it. Relatedly, kernelCTF just announced they will be disabling user namespaces, which is probably a good idea if they are inundated with exploits: https://github.com/google/security-research/commit/7171625f57154db3c1a67b820d84650ece88ed2a https://github.com/google/security-research/commit/7171625f5...

Aurornis 1y ago

The server was open every 2 weeks. The proof of work was to slow down connections slightly to reduce incentives to spam as many connection requests as possible. Public CTFs are hard because inevitably some team will try something resembling a DDoS as part racing to the finish. Google removed the proof of work step after this.