I'm the one who wrote this.I originally tried submitting it here myself but without much luck so glad to see someone else shared it! Thanks for bringing it here.
also if anyone has another working PoC for that specific build I'd really appreciate if they could share it because looking at how the exploit works it does something that is not done on any other solution that i found for other builds, none of them hold the spot with a resize (key “1050” is sent twice) than make an intermediate buffer from the next field("1999") fall there.it’s the only approach I’ve seen that uses a repeated key like that.
I wonder whether there's a more direct way to achieve that as in the solutions for other builds. If there is, I think it would be interesting to compare the reliability of the different approaches based on the memory manipulation itself rather than how they reach the target
I'm not sure you're going to see different outcomes with discussion this time around.
It's way too much text, branching out to explain too many things, has LLM-ism flavours to many sentences, and the AI generated images are not additive to your content.
For me to read it, it would need to be very much trimmed down in size (at most to 25% of current size) and punctual on what you've done instead of all the things that sidetrack the article.
I agree that it's way too long and difficult to find the value in. One of the key features of a lot of good longer-form informational writing is that it goes around a subject before it goes into a subject. This takes many forms (and is, indeed, kind of fractal), but on its most basic level it's the "this is what I'm going to tell you, here let me tell you, now this is what I told you" pattern. And I say "fractal" because it applies not just to the whole thing, but to every chapter, and so forth. Even paragraphs often bear this structure.
When I don't know what you're going to tell me, I lose interest. When I hit descriptions of memory freeing right away, I don't know: are we going to blather in the weeds about pointers or malloc or ... ? When am I going to get to the part that's new to me? Etc. It's just hard to read, if I don't have to read it.
LLMs make this a whole lot worse because they don't need context like human readers and authors do. They can just jump right in. So they don't care, and they won't flag this, and if you end up writing for them, your writing won't be valuable to humans who need to learn.
yes i understand that the problem is that I was writing this as I was investigating. I had a huge file of notes that I kept adding to as I went, than got back to add again each time and eventually turned that into the writeup. So what you're reading is quite literally my path towards understanding, rather than something I wrote afterwards with a predefined structure and roadmap, and once i finished i went back through the article, I realized I wanted to make some of the more complicated topics easier to understand and more accessible to everyone. So I added a few more sections including explanations of fundamentals that are just meant for people that doesn't have experience with low level programming
I agree with the cutesy images, but for the rest ... it's called a deep dive, and it delivers. 25% of it might still have enough context about the bug and exploit, but would lose on the journey the OP went through to get to that point.
well it is a deep dive if i just shrink its size to 25% it would be the same thing that already exists around, calif itself did an article on it and there are thousands of articles around that say little to nothing about it, they just explain the thing on the surface so honestly i dont see the purpose on doing another thing like that, this is meant to show everything in detail, i know not lot of people will read it, it was not made to be read by a mass audience but the few that will at least i hope that they will deeply understand what's happening. for the images well since its a long writeup i tried to make it a little less boring by taking some inspiration from how Calif's Research Lab presents their work, cause i've always found there way of showing things intresting and its different than everything else out there, in the end the writeup has my personality on it and when i write something i always like to do it in my own way.if I showed you my internship reports, university presentations and other writeups, you'd probably notice the same style I just like doing things in a way that I enjoy.
Apart from being a bit too long, this is the only writeup I've found that explores the vulnerability in such depth. The technical content is excellent and extremely well explained. It would be great to see a more summarised and structured version in the future. Great work!
I'm the one who wrote this.I originally tried submitting it here myself but without much luck so glad to see someone else shared it! Thanks for bringing it here.
also if anyone has another working PoC for that specific build I'd really appreciate if they could share it because looking at how the exploit works it does something that is not done on any other solution that i found for other builds, none of them hold the spot with a resize (key “1050” is sent twice) than make an intermediate buffer from the next field("1999") fall there.it’s the only approach I’ve seen that uses a repeated key like that.
I wonder whether there's a more direct way to achieve that as in the solutions for other builds. If there is, I think it would be interesting to compare the reliability of the different approaches based on the memory manipulation itself rather than how they reach the target
I'm not sure you're going to see different outcomes with discussion this time around.
It's way too much text, branching out to explain too many things, has LLM-ism flavours to many sentences, and the AI generated images are not additive to your content.
For me to read it, it would need to be very much trimmed down in size (at most to 25% of current size) and punctual on what you've done instead of all the things that sidetrack the article.
I agree that it's way too long and difficult to find the value in. One of the key features of a lot of good longer-form informational writing is that it goes around a subject before it goes into a subject. This takes many forms (and is, indeed, kind of fractal), but on its most basic level it's the "this is what I'm going to tell you, here let me tell you, now this is what I told you" pattern. And I say "fractal" because it applies not just to the whole thing, but to every chapter, and so forth. Even paragraphs often bear this structure.
When I don't know what you're going to tell me, I lose interest. When I hit descriptions of memory freeing right away, I don't know: are we going to blather in the weeds about pointers or malloc or ... ? When am I going to get to the part that's new to me? Etc. It's just hard to read, if I don't have to read it.
LLMs make this a whole lot worse because they don't need context like human readers and authors do. They can just jump right in. So they don't care, and they won't flag this, and if you end up writing for them, your writing won't be valuable to humans who need to learn.
yes i understand that the problem is that I was writing this as I was investigating. I had a huge file of notes that I kept adding to as I went, than got back to add again each time and eventually turned that into the writeup. So what you're reading is quite literally my path towards understanding, rather than something I wrote afterwards with a predefined structure and roadmap, and once i finished i went back through the article, I realized I wanted to make some of the more complicated topics easier to understand and more accessible to everyone. So I added a few more sections including explanations of fundamentals that are just meant for people that doesn't have experience with low level programming
I agree with the cutesy images, but for the rest ... it's called a deep dive, and it delivers. 25% of it might still have enough context about the bug and exploit, but would lose on the journey the OP went through to get to that point.
exactly and at the time I wasn’t planning for it to end up on Hacker News. if I knew I woul've made it much more direct without all the basics
well it is a deep dive if i just shrink its size to 25% it would be the same thing that already exists around, calif itself did an article on it and there are thousands of articles around that say little to nothing about it, they just explain the thing on the surface so honestly i dont see the purpose on doing another thing like that, this is meant to show everything in detail, i know not lot of people will read it, it was not made to be read by a mass audience but the few that will at least i hope that they will deeply understand what's happening. for the images well since its a long writeup i tried to make it a little less boring by taking some inspiration from how Calif's Research Lab presents their work, cause i've always found there way of showing things intresting and its different than everything else out there, in the end the writeup has my personality on it and when i write something i always like to do it in my own way.if I showed you my internship reports, university presentations and other writeups, you'd probably notice the same style I just like doing things in a way that I enjoy.
Apart from being a bit too long, this is the only writeup I've found that explores the vulnerability in such depth. The technical content is excellent and extremely well explained. It would be great to see a more summarised and structured version in the future. Great work!
Ended up with 25GB RAM usage in Firefox reading this site. What's wrong.
Great writeup! Go into it with time set aside to actually deep dive.
The most impressive this was chaining this exploit with another linux exploit to gain root access.
A week to go down in history.