Crispin Cowan wrote: > Gerardo Richarte wrote: > > > I think that having this kind of overflow available, StackWard is > > still vulnerable to a little smarter attack. > > > > You may think that this code example is too tricky, but there was a > > buffer overflow in bind's inverse query > > (http://www.securityfocus.com/vdb/bottom.html?vid=134) like this. This > > makes me remember of some code I wrote to exploit this for Sparcs, as > > it was just one call deep, it was imposible to overwrite the return > > address, so, by using a memcpy() to a pointer I could overwrite (like > > that one in > > the example code) I overwrited part of the libc in memory, lets say > > printf, so when the program called printf() after the second memcpy(), > > instead of calling the original printf() it called my code: Here you > > have an exploit that can be used still if you have StackWard. > > You appear to be describing a buffer overflow that attacks a pointer, and no hes describing an attack that exploits a buffer overflow, the particular case is that the vulnerability allows the attacker to overwrite a pointer, the ways to exploit that are many, Gerardo mentions overwritting a libc function, other things that come to mind: . Modifying the PLT . Modifying the GOT . Modifiying the _dynamic struct . Overwritting global variables (i somehow recall an exploit that modifies a global FILE struct under some *BSD flavor) . Overwritting C++ object destructors > > not the activation record. StackGuard only claims to protect the > activation record, so while this is a legitimate vulnerability that > StackGuard does not prevent, it is not actually a bug in StackGuard. > Well, your original post said: > Consider this vulnerable code: > > foo(char * arg) { > char * p = arg; // a vulnerable pointer > char a[25]; // the buffer that makes the pointer vulnerable > > gets(a); // using gets() makes you vulnerable > gets(p); // this is the good part > } > > In attacking this code, the attacker first overflows the buffer a[] with > a goal of changing the value of the char * p pointer. Specifically, > the attacker can cause the p pointer to point anywhere in memory, > but especially at a return address record in an activation record. > When the program then takes input and stores it where p points, the > input data is stored where the attacker said to store it. > "in attacking this code" is a key phrase here... I believe Gerardo tries to say that it is posible to attack that code in many different ways and therefore: > 3. Solution: The XOR Random Canary > It is not so. It's just a way to prevent ONE kind of exploitation of that code > > The result of this method is that we have the same protection as with > the classic Random canary, and also the property that the attacker cannot Exactly, "the same protection" It just doesnt fix the problem of exploiting the code in a way that does not involve: > > modify the return address without invalidating the canary word. This in no way implies that StackGuard is not an effective solution against common buffer overflow vulnerabilities and the usual way of exploiting them, but i think its importart to point out exactly against what it DOES protect you and against what it DOESNT. that said, i now run to trademark StackWard.... btw, what about StackWars? -ivan -- "Understanding. A cerebral secretion that enables one having it to know a house from a horse by the roof on the house, It's nature and laws have been exhaustively expounded by Locke, who rode a house, and Kant, who lived in a horse." - Ambrose Bierce ==================[ CORE Seguridad de la Informacion S.A. ]============= Iván Arce Presidente PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1 F65A email : iarce@core-sdi.com http://www.core-sdi.com Pte. Juan D. Peron 315 Piso 4 UF 17 1038 Capital Federal Buenos Aires, Argentina. Tel/Fax : +(54-11) 4331-5402 Casilla de Correos 877 (1000) Correo Central ================================================================ --- For a personal reply use iarce@core-sdi.com
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:11:11 PDT