by pi3

One day I was reviewing all bugs in bugtraq IDs (popular bids). I want to know which kind of bugs is it now popular and what is the trend of modern bugs. I came to two main conclusions:

1) The most popular are SQL/XSS bugs but in 60% this is found in software which nobody knows/uses (stupid kiddie)

2) We’ve got 2010 year and there is still possible to find stack overflow bugs! The most funny thing for me there is more remote stack overflow bugs than local 🙂

Stack overflow bugs is one of the oldest class of software bugs which still exists – more-less 10% of all bugs ! Of course it isn’t 199x year that you can find it using regexpression for ‘grep’ program. So what is conclusion? Exploit stack overflow bugs is still interesting from attackers point of view. The question is “Is it still possible to exploit this class of bugs in modern UNIX systems in 2010 year?”. The answer for this question isn’t simple. Let’s do simple review of modern defence systems. We’ve got:

*) Non-exec memory (not only stack – almost every region where it is NOT necessary)
*) W^X – “Write XOR Exec” memory. It forbids memory with Write and Exec bits in the same time.
*) AAAS – ASCII Armored Address Space
*) ASLR – Address Space Layout Randomization
*) mmap() and mprotect() protections
*) Heap protections – like safe-unlink(), safe malloc() implementation (OpenBSD)
*) Random canary of death protections                       ——————————-|
*) frame pointer protection by canary of death                                                |
*) move all pointers to the beginning of the frame                                           |==>  pro-police
*) move all local byte arrays to the end of the frame                                       |        protection (SSP)
*) Vulnerable arguments copied to the local variables and then reordered—-|

We can bypass most of this protection but if it isn’t connected. Is there any possibilities to exploit in modern UNIX systems REMOTE stack overflow bugs with enabled ALL of this protections?! It sounds crazy… but STILL we CAN DO IT 🙂 I wrote simple server with remote stack overflow bug and EXPLOIT it. Proof Of Concept of course is private but I created a movie of exploiting. You can find it here:


We’ve got 2010 year and we can still exploit remote stack overflow bugs in modern UNIX systems 🙂 Amazing… but it could be that this techniques (yes it isn’t one technique which is used to exploit this bug) is the last opportunity to exploiting remote stack overflow bugs… OK so… have a nice watching 🙂

Best regards,

Adam Zabrocki


  1. z33d on 03.18.2010

    Is there any new concept or ninja trick? For me
    it seems that it’s nothing new, you simply brute force canary value, guessing one byte at time. Or am I wrong?

  2. admin on 03.18.2010

    Yes, there is. Canary is only one of the defence which i bypass remotely. Problem is to bypassing all protections using remote attack. This show it is possible.

  3. Gu1 on 03.19.2010

    Another article with more details about how you did it would be great. That would be much more explanatory than this video.

  4. Newlog on 04.28.2010

    I’m with Gu1 😀

  5. etho on 05.25.2010

    Can you public code of vulnerable server?

  6. admin on 05.25.2010

    I’m preparing paper about details how to exploit remote stack overflow bugs. There will be server and exploit code…

  7. dev/null on 05.27.2010

    I belive the reason there is more remote b0f now is because the amount of network service based s.w has dominated the market,

  8. h00w on 06.23.2010

    w00w its so elite :)) are u planning to release a paper about your technique? i will wait for it :))

  9. admin on 06.24.2010

    Probably yes, but I don’t know when and where 😉

  10. klondike on 12.06.2010

    Is funny how new random canaries are not generated on each fork() call. Of course the ASLR bypass is unavoidable although I’d like to see that exploit working on an amd64 machine 😛

    The funny thing is that it is very easy to fix.

  11. admin on 12.06.2010

  12. a on 06.22.2012


    Source code of this?
    twitter handle?:)


  13. admin on 06.22.2012

    It is public since November 2011 as part of my publication in Phrack magazine. Please take a look here:


  14. a on 06.24.2012

    Yeah, I have already found it, thanks!
    I’m the guy who added you on LI also.

Leave a Reply

CAPTCHA * Time limit is exhausted. Please reload the CAPTCHA.