Readit News logoReadit News
OneLessThing commented on No Leak, No Problem – Bypassing ASLR with a ROP Chain to Gain RCE   modzero.com/en/blog/no-le... · Posted by u/todsacerdoti
nneonneo · 3 months ago
If I read this correctly, they’re “bypassing ASLR” because the binary isn’t PIE, so it’s loaded at a static address.

I would not consider this actually bypassing ASLR, because ASLR is already turned off for a critically important block of code. Practically any large-enough binary has gadgets that can be useful for ROP exploitation, even if chaining them together is somewhat painful. For ASLR to be a reasonably effective mitigation, every memory region needs to be randomized.

OneLessThing · 3 months ago
Yeah :/ that’s how I read it too. It would make more sense if they motivated the reason to find libc because like you said you could likely just use the non aslr gadgets exclusively. I think the author tried to use non aslr gadgets but had issues so went to the approach of using the GOT libc address and called that approach “bypassing ASLR”.

It’s a matter of opinion I guess. In the early days of ASLR it was common to look for modules that were not position independent for your ROP chain and that process was probably called bypassing aslr. These days we’d probably just call that not being protected by aslr.

OneLessThing commented on No Leak, No Problem – Bypassing ASLR with a ROP Chain to Gain RCE   modzero.com/en/blog/no-le... · Posted by u/todsacerdoti
OneLessThing · 3 months ago
Good job. It’s early 2000s level stuff but it’s still exciting when it’s happening on your desk. There are lots of options in this scenario outside of bypassing ASLR so I do find it odd to be the main feature of the title, but a fun read nonetheless.

It’s fun working on targets with a less established research history. And I love a soup to nuts writeup, Thanks.

OneLessThing commented on Love C, hate C: Web framework memory problems   alew.is/lava.html... · Posted by u/OneLessThing
lifthrasiir · 4 months ago
Yeah, I recently wrote a moderate amount of C code [1] entirely with Gemini and while it was much better than what I initially expected I needed a constant steering to avoid inefficient or less safe code. It needed an extensive fuzzing to get the minimal amount of confidence, which caught at least two serious problems---seriously, it's much better than most C programmers, but still.

[1] https://github.com/lifthrasiir/wah/blob/main/wah.h

OneLessThing · 4 months ago
This is exactly my problem with LLM C code, lack of confidence. On the other hand, when my projects get big enough to the point where I cannot keep the code base generally loaded into my brains cache they eventually get to the point where my confidence comes from extensive testing regardless. So maybe it's not such a bad approach.

I do think that LLM C code if made with great testing tooling in concert has great promise.

OneLessThing commented on Love C, hate C: Web framework memory problems   alew.is/lava.html... · Posted by u/OneLessThing
uecker · 4 months ago
I strategy that helps me is just not use open-coded pointer arithmetic or string manipulation but encapsulate those behind safe bounds-checked interfaces. Then essentially only life-time issues remain and for those I usually do have a simple policy and clearly document any exception. I also use signed integers and the sanitizer in trapping mode, which turns any such issue I may have missed into a run-time trap.
OneLessThing · 4 months ago
This is why I love C. You can build these guard rails at exactly the right level for you. You can build them all the way up to CPython and do garbage collection and constant bounds checking. Or keep them at just raw pointer math. And everywhere in between. I like your approach. The downside being that there are probably 100,000+ bespoke implementations of similar guard rails where python users for example all get them for free.
OneLessThing commented on Love C, hate C: Web framework memory problems   alew.is/lava.html... · Posted by u/OneLessThing
lelanthran · 4 months ago
I can't completely blame the language here: anyone "coding" in a language new to them using an LLM is going to have real problems.
OneLessThing · 4 months ago
It's funny the author says this was 90% written without AI, and that AI was mostly used for the json code. I think they're just new to C.

Trust me I love C. Probably over 90% of my lifetime code has been written in C. But python newbies don't get their web frameworks stack smashed. That's kind of nice.

OneLessThing commented on Love C, hate C: Web framework memory problems   alew.is/lava.html... · Posted by u/OneLessThing
uecker · 4 months ago
I do not agree that the integer promotion or casting (?) rules are broken in C. That some people make mistakes because they do not know them is a different problem.

The reason you should make length signed is that you can use the sanitizer to find or mitigate overflow as you correctly observe, while unsigned wraparound leads to bugs which are basically impossible to find. But this has nothing to do with integer promotion and wraparound bugs can also create bugs in - say - Rust.

OneLessThing · 4 months ago
It's interesting to hear these takes. I've never had problems catching unsigned wrap bugs with plain old memory sanitizers, though I must admit to not having a lot of experience with ubsan in particular. Maybe I should use it more.
OneLessThing commented on Love C, hate C: Web framework memory problems   alew.is/lava.html... · Posted by u/OneLessThing
jacquesm · 4 months ago
There are many, many more such issues with that code. The person that posted it is new to C and had an AI help them to write the code. That's a recipe for disaster, it means the OP does not actually understand what they wrote. It looks nice but it is full of footguns and even though it is a useful learning exercise it also is a great example of why it is better run battle tested frame works than to inexpertly roll your own.

As a learning exercise it is useful, but it should never see production use. What is interesting is that the apparent cleanliness of the code (it reads very well) is obscuring the fact that the quality is actually quite low.

If anything I think the conclusion should be that AI+novice does not create anything that is useable without expert review and that that probably adds up to a net negative other than that the novice will (hopefully) learn something. It would be great if someone could put in the time to do a full review of the code, I have just read through it casually and already picked up a couple of problems, I'm pretty sure that if you did a thorough job of it there would be many more.

OneLessThing · 4 months ago
I agree that it reads really well which is why I was also surprised the quality is not high when I looked deeper. The author claims to have only used AI for the json code, so your conclusion may be off, it could just be a novice doing novice things.

I suppose I was just surprised to find this code promoted in my feed when it's not up to snuff. And I'm not hating, I do in fact love the project idea.

OneLessThing commented on Show HN: I built a web framework in C   github.com/ashtonjamesd/l... · Posted by u/ashtonjamesd
OneLessThing · 4 months ago
There is a heap overflow in the http parser. Should I spoil it or let people find it on their own?
OneLessThing · 4 months ago
Heres a link to the the problem I found: https://alew.is/lava.html
OneLessThing commented on Show HN: I built a web framework in C   github.com/ashtonjamesd/l... · Posted by u/ashtonjamesd
OneLessThing · 4 months ago
There is a heap overflow in the http parser. Should I spoil it or let people find it on their own?

u/OneLessThing

KarmaCake day168December 8, 2014View Original