Hacker Newsnew | past | comments | ask | show | jobs | submit | dunder_cat's commentslogin

After CVE-2023-7028 (account takeover via password reset, IIRC you just had to add a semi-colon between the correct email and the attacker email and it'd email both) was exploited against my cluster, the boasting about fully-automated changes and reviews scares me. I hope I'm far from the only one that hasn't forgotten issues like this.

I'm aware that the defective code was not written by AI but nonetheless, GitLab is what stands between many small organizations and their most precious resources. I was fortunate that 2FA stopped the damage, but what's going to happen the next time? What if my organization is permanently damaged because we taught the machines to go fast and break things, too [1]?

[1] VPN is an option but we're a non-profit with a number of non-technical users, so admittedly we're caught in a balance between making it harder to do things. As much as WireGuard is awesome, there's still a barrier.


> [1] VPN is an option but we're a non-profit with a number of non-technical users, so admittedly we're caught in a balance between making it harder to do things. As much as WireGuard is awesome, there's still a barrier.

I would love to help a non-profit and so, I am curious but what are your thoughts on authentik/authelia and others, can they might help in any use case to what you are suggesting, I would love to have a more in-depth discussion!

Also thanks for working at non-profit, although I am not entirely sure what is about but thanks to your non profits and all the other hard working people working at non profits for a better world once again!


Your understanding is fine. In many environments, you can still do a lot of damage just by popping a shell and being able to access the database/sensitive environment variables/sensitive code. Getting to root would just be the icing on the cake.

That being said, it's pretty common for non-containerized processes to drop permissions to a low-privileged service account (like nginx running as `nobody`), so it definitely thwarts defense-in-depth in those setups.

In containerized environments, my understanding is their use of namespaces means you still need something more clever than just "patch out the authentication logic in su via the page cache" to escalate permissions in the system to break out of the container. That doesn't mean it's impossible in these exploits (the original copyfail writeup alluded to a second writeup coming to this effect - distinct from dirtyfrag though), but it does mean you're not going to be able to just spam the PoCs floating around.


Also, meant to share some interesting readings. In the Kubernetes world, my RSS feed lit up with their blog post about user namespaces being generally available in k8s 1.36.

They actually provided some example CVEs that wouldn't have been possible if in addition to containers, they were also using user namespaces https://github.com/kubernetes/enhancements/tree/217d790720c5.... The first example talks about "CVE-2019-5736: Host runc binary can be overwritten from container. Completely mitigated with userns." So it seems like getting root in a regular container gives you more of an attack surface, but if user namespaces are deployed, then it's even harder to do anything useful with it. I am looking forward to the aforementioned writeups since user namespace escapes usually mean another kernel bug.


Doesn't have to even be that advanced, people get conditioned to stuff like reCAPTCHA and friends & Cloudflare's interstitial landing page (when "I'm under attack" mode is on) and they won't bat an eye. That's how we get people piping `curl | bash` into their terminal to "solve" fake challenges.

As a side note though, I recently have tried to turn CSP on a website I run and the amount of garbage I see in the reports is astonishing. There's some noise from things like OpenDNS intercepting YouTube or Social embeds for people using the work-friendly or family-friendly options, but the sheer amount of things attempting to phone home to random URLs and random extension scripts injecting ads into the site would astonish you. My mental model of "toolbar hell" from the Windows XP days being gone has completely shattered.


Is the QR code check mandatory and if not, is it the default?

The bulletpoint as-is just says:

> AI-resistant challenge: As we identify potentially fraudulent behavior from agents, we enable application providers to deter and mitigate malicious requests by requesting humans to be in the loop using the new QR code-based challenge. This AI-resistant mitigation challenge to prove human presence is designed to make automated fraud economically unviable.

Followed by

> Existing reCAPTCHA customers are automatically Fraud Defense customers, with no migration required, no action needed, and no change to pricing. Your existing site keys and integrations remain exactly as they are today.

It is probably me being a literal reader but "we enable application providers to deter and mitigate malicious requests by requesting humans to be in the loop" feels like it can be read as "Good news: by using reCAPTCHA, we're now interfering with agents that can solve the regular challenges" or "there's now a flag the application developer can set". This is the difference between me swapping off reCAPTCHA ASAP or just editing my configuration. I have to imagine someone somewhere anticipated the kind of reactions a number of us are collectively feeling (I too don't want to use my phone to browse the web more than I already do) and it feels irresponsible to publish a feature announcement without covering basic information like this for site administrators. Maybe they thought the second line about existing reCAPTCHA customers being moved over clears this up, but "Your existing ... integrations remain exactly as they are today" feels like again, literally, you won't have this new attestation requirement being presented to your users... but then why am I Fraud Defense customer!


A more direct source (possibly the original source?) I know of is a YouTube video entitled "LISA11 - Fork Yeah! The Rise and Development of illumos" which detailed how the Solaris operating system got freed from Oracle after the Sun acquisition.

The whole hour talk is worth a watch, even when passively doing other stuff. It is a neat history of Solaris and its toolchain mixed with the inter-organizational politics.

YouTube link: https://www.youtube.com/watch?v=-zRN7XLCRhc

Direct link to lawnmower quotes (~38.5 minute mark): https://youtu.be/-zRN7XLCRhc&t=2307


Instagram needs to do this for Reels, too. I got quite addicted to these short-form videos during the pandemic and after I finished college things went immediately downhill once a lot of my mental activity could be somewhat "deferred". I could make up for the productivity hit by crunching but my life would be better without them. I remove things from my phone or put services into Pi-Hole but eventually I capitulate. Something about having the option to remove the most addicting parts of a service but not cutting yourself off completely has more success.

Edit: also to be somewhat objective, Instagram also offers a time limit. However, I've found that just by exiting the app (or it getting killed in the background), it basically clears the lockout so you don't even have to make the effort to click the "ignore" button.


Chiming in as well to say to the author when the victory lap here is over: please consider adding the RSS feed! I want to see whatever you do next, regardless of how long it takes.


Here's another polite request for an RSS feed. Thank you


Just adding for posterity that the RSS feed appears to be functional now


> Edit: This is going to have huge ramifications for the tech security industry as these systems will be able to break security systems as easily it solved the proof. The sooner the good guys, if there are any left, understand this the better it will be for everybody.

What can the good guys do? Fire up Claude to improve their systems? Unless you have it working fully autonomously to counter-act abuse, I don't see how you can beat the "bad guys". There may be some industries where this is a solved problem (e.g. you can do all the validation server-sided, religiously follow best practices to prevent and mitigate abuse), but a lot of stuff like multiplayer video games will be doomed unless they move to a "you must use a locked down system we control" model. I honestly don't consider it liberating as someone that has various hobby projects, that now in addition to plain old DDoS I'll also have people spin up layer 7 attacks with just their credit card. It almost makes me want to give up instead of pushing forward in a world where the worst of the worst has access to the best of the best.


Nothing as heavy as the above but here's my small anecdote:

I was putting off security updates on my npm dependencies in my personal project because it's a pain to migrate if the upgrade isn't trivial. It's not a critical website, but I run npm scripts locally, and dependabot is telling me things.

I told Claude Code to make a migration plan to upgrade my deps. It updated code for breaking changes (there were API changes, not all fixes are minor version upgrades) and replaced abandoned unmaintained packages with newer ones or built-in Node APIs. It was all done in an hour. I even got unit tests out of it to test for regressions.

In this case, I was able to skip the boring task of maintaining code and applying routine updates and focus on the fun feature stuff.


I am curious, have you attempted to do this to any binary packed with commercial obfuscation/"virtualization" schemes (e.g. Orean's Themida/Code Virtualizer and VMProtect)?


No, I would need to find a binary to test on. I suspect it would produce horrible code at the decompiler layer but ultimately I would expect that function signatures are still relatively clean?

Its scary - once you get the differential testing harness set up it seems to be just a matter of time/tokens for it to stubbornly work through it.



It's up.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: