lobsters score: 2 · tags: security
This does not explain how a UaF results in server provided code becoming executable. My only explanation would be if curl handles PAC files and uses a JS engine with a JIT or similar that maps a page as executable.
score 1 · canonical
So the use-after-free is in the “handle” being reused and overwritten. That doesn’t require a JS engine, just a curl session that does multiple HTTP transfers.
Sadly, the attached diagram doesn’t really explain why data downloaded from the server is overwriting the data structures and how that leads to code execution - maybe overwriting a function pointer? It also doesn’t explain what the multiple requests are, it just says “when uploading”, but I can only presume that’s the first request, not the only request.
The prerequisites for the attack also look odd?
The attacker needs to know curl’s architecture to generate and deliver the right code Right. Every attacker needs that all the time?! Or is this about endianness etc.?
Then, the blog post also says
Please refer to the original report for all the details
But I couldn’t find a link?
score 1 · canonical
I think I misread what they were saying (or they phrased it poorly). They presumably mean arbitrary code execution: e.g the hacker has overwritten a function pointer and taken over the control flow rather than “the server has provided the executable code”.
I feel the phrasing at least is weird, but if we assume the above then it’s just a standard UaF->code pointer corruption. Handling ASLR, varying code layout, etc is a fairly well understood problem space - assuming the right info leaks exist those mitigations can be fairly easily resolved, the mitigations are insufficient on their own, they just increase the number of concurrent bugs needed (but for experienced attackers they’re still just a minor step).
score 1 · canonical