tag:blogger.com,1999:blog-7445701319591354935.comments2023-03-10T14:34:01.289+01:00add more NOPs!infihttp://www.blogger.com/profile/00547855212089123529noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-7445701319591354935.post-85846147839903943002008-10-20T10:57:00.000+02:002008-10-20T10:57:00.000+02:00What I meant to say is that in the paper, the auth...What I meant to say is that in the paper, the author places the shellcode towards the mid-late area of buf1 and thus the early area (where fd and bk are stored once its freed) is free for malloc manipulation, which in my particular exploit wasn't the case. I thought malloc would smash the beginning of the shellcode when executing free(buf1) and when .dtors redirected execution towards buf1, the area would be trashed.<BR/><BR/>I just made some tests to prove my concept but didn't work out. Perhaps Im missing something here. I manage to overwrite the .dtors section but when free(buf1) happens, _int_free() crashes with a SIGSEGV when performing unlink() because edi holds 0xffffffff (-1).<BR/><BR/>I guess this needs a deeper analysis, I leave that for some time in the future. Yet again, thanks for showing interest in the matter and contributing :-)infihttps://www.blogger.com/profile/00547855212089123529noreply@blogger.comtag:blogger.com,1999:blog-7445701319591354935.post-16982344737885425632008-10-19T19:41:00.000+02:002008-10-19T19:41:00.000+02:00mmm maybe I'm not getting exactly what you say, bu...mmm maybe I'm not getting exactly what you say, but as far as I can see overwriting .dtors is exactly the same as overwriting the GOT.<BR/><BR/>I.e., you just place the .dtor's address minus 12 in one of the pointer, your shellcode's address minus 8 in the other one, and you start your shellcode with something like [jump over garbage][garbage][the actual shellcode] so that the garbage is clobbered.<BR/><BR/>I'm just taking it from the top of my mind, but I'm pretty sure I've used this technique when learning about heap overflows a while ago.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7445701319591354935.post-87189496785050038942008-10-19T17:47:00.000+02:002008-10-19T17:47:00.000+02:00First of all thanks for the feedback and note that...First of all thanks for the feedback and note that I'm very glad for it.<BR/><BR/>I've taken a look at the paper and althought I'll try to make some research on it my first guess is as follows: Overwriting the .dtors section looks feasible but for that to be possible we need to alter the buffer and move it towards the middle-late position of the buffer(It's on the beginning of it in this example). <BR/><BR/>Since free() is called on buf1, the first 8 bytes need to be free-of-use for us because pointers will be moved around there and when execution gets there through .dtors, the first 8 bytes(which in our exploit make for the "jmp") will be clobbered by the traditional way free works. Hence, when the .dtors section gets there's no executable code is waiting but garbage from malloc management.<BR/><BR/>Thats the idea that first pops into my mind, but as I said I'll try to get a more hands-on answer. Thanks again for taking the time to elaborate on that, hope to see you around again! :-)infihttps://www.blogger.com/profile/00547855212089123529noreply@blogger.comtag:blogger.com,1999:blog-7445701319591354935.post-4992014708653462082008-10-19T17:05:00.000+02:002008-10-19T17:05:00.000+02:00Just a quick note on it.Besides overwriting the GO...Just a quick note on it.<BR/><BR/>Besides overwriting the GOT entry for free(), it is also possible to exploit such a bug by overwriting the .dtors section and introducing the address of your shellcode in there.<BR/><BR/>For instance, this paper (which I just found using google and never read) talks about it: http://www.infosecwriters.com/texts.php?op=display&id=19<BR/><BR/>Keep on adding NOPs, it's a nice blog to read and I'm looking forward to read more info on advanced topics here :)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7445701319591354935.post-17514924242501072462008-08-31T13:47:00.000+02:002008-08-31T13:47:00.000+02:00Despite the last line in the blog, I'm in summer v...Despite the last line in the blog, I'm in summer vacation right now so no more updates until mid-late september I guess. Thanks for dropping by :)infihttps://www.blogger.com/profile/00547855212089123529noreply@blogger.comtag:blogger.com,1999:blog-7445701319591354935.post-71754513438253831542008-08-30T20:03:00.000+02:002008-08-30T20:03:00.000+02:00You are amazing!You are amazing!Manu Piratahttps://www.blogger.com/profile/08480812058486497614noreply@blogger.comtag:blogger.com,1999:blog-7445701319591354935.post-53062229246772709272008-07-29T22:52:00.000+02:002008-07-29T22:52:00.000+02:00Nice point there, that made it clearer, thanks for...Nice point there, that made it clearer, thanks for that. I guess I lack some in field work :-), that's to come in the future. I'll enjoy my little warm bubble for now :Dinfihttps://www.blogger.com/profile/00547855212089123529noreply@blogger.comtag:blogger.com,1999:blog-7445701319591354935.post-55828171261087510332008-07-28T13:57:00.000+02:002008-07-28T13:57:00.000+02:00An small addition to the second paragraph of my pr...An small addition to the second paragraph of my previous comment: if it doesn't satisfy user needs, then our product will not be used... which is other's work goal.deshttps://www.blogger.com/profile/05700818605082563617noreply@blogger.comtag:blogger.com,1999:blog-7445701319591354935.post-49441342449381501532008-07-28T13:53:00.000+02:002008-07-28T13:53:00.000+02:00I'll try another aproximation:As security practiti...I'll try another aproximation:<BR/><BR/>As security practitioners working in a development team, our goal is to have a 100% secure product. It's our job, we have to keep working hard to achieve it. It's not just you, infi, that is my own philosophy, too, and the idea of almost everyone working in this field ;)<BR/><BR/>However, as we have difficulties trying to educate people in security, we tend to insist that much in the importance of security, that looks like we forget about other's work. We can develop the most secure program of the world, but it will not matter if it doesn't satisfy user needs. That was the idea if my first comment.<BR/><BR/>As well as this, we have our ego: we like to have credit if we discover a vulnerability, we want to be known and if possible, be called "hackers". Maybe it is this what linus means by saying "masturbating monkeys". In other fields (in my opinion) people do not care that much about recognition. In order to make others listening to us, we should make clear we respect their work, whatever it is. <BR/><BR/>Maybe linus' words are hard, but they are a good criticism we should take into account.deshttps://www.blogger.com/profile/05700818605082563617noreply@blogger.comtag:blogger.com,1999:blog-7445701319591354935.post-22790643812479976932008-07-25T05:20:00.000+02:002008-07-25T05:20:00.000+02:00Hi des! :)Maybe it's just my innocent point of vie...Hi des! :)<BR/><BR/>Maybe it's just my innocent point of view but avoiding security in the process is just building something waiting to malfunction, which doesn't fit much in my "good enough" rating. But again...it's just me.infihttps://www.blogger.com/profile/00547855212089123529noreply@blogger.comtag:blogger.com,1999:blog-7445701319591354935.post-72720551309115505612008-07-23T16:05:00.000+02:002008-07-23T16:05:00.000+02:00Hi infi! Glad to see you continue writing :) Just ...Hi infi! Glad to see you continue writing :) <BR/><BR/>Just a comment: If we don't take into account the not-very-well-educated comments (masturbating monkeys??), I think Torvals has got his point: there is no point in security, if the product is not good enough to satisfy user needs.deshttps://www.blogger.com/profile/05700818605082563617noreply@blogger.comtag:blogger.com,1999:blog-7445701319591354935.post-48303559093825322152008-06-05T09:34:00.000+02:002008-06-05T09:34:00.000+02:00Thanks for bothering to comment in the first place...Thanks for bothering to comment in the first place :)<BR/><BR/>The shellcoder's handbook is great, althougth at some points it requires some background knowledge and the learning curve is a bit steep it delves into some aspects of vulnerability research and exploit development that make it a MUST have.infihttps://www.blogger.com/profile/00547855212089123529noreply@blogger.comtag:blogger.com,1999:blog-7445701319591354935.post-56304830377618158712008-06-05T00:31:00.000+02:002008-06-05T00:31:00.000+02:00I'm looking forward to read the shellcoder's handb...I'm looking forward to read the shellcoder's handbook. Seems it is, at least, inspiring :)<BR/><BR/>Congratulations for starting the <I>blogging adventure</I>. Best regards.deshttps://www.blogger.com/profile/05700818605082563617noreply@blogger.com