The following was taken directly from the Immunix advisory: A significant security vulnerability has been discovered by Mariusz Woloszyn <emsi@it.pl> that permits attackers to perpetrate successful attacks against StackGuarded programs under particular circumstances. Woloszyn is preparing a Phrack article describing this vulnerability, which we summarize here. StackGuard 1.21 effectively protects against this vulnerability. The Immunix team would like to thank Mariusz for kindly notifying us first about this vulnerability, and allowing us the time to develop and distribute a defense. 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...
The following was taken directly from the Immunix advisory: A significant security vulnerability has been discovered by Mariusz Woloszyn <emsi@it.pl> that permits attackers to perpetrate successful attacks against StackGuarded programs under particular circumstances. Woloszyn is preparing a Phrack article describing this vulnerability, which we summarize here. StackGuard 1.21 effectively protects against this vulnerability. The Immunix team would like to thank Mariusz for kindly notifying us first about this vulnerability, and allowing us the time to develop and distribute a defense. 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. The above attack is effective against the Random and Terminator Canary mechanisms because those methods assume that the attack is linear, i.e. that an attacker seeking to corrupt the return address must necessarily use a string operation that overflows an automatic buffer on the stack, moving up memory through the canary word, and only then reach the return address entry. The above attack form, however, allows the attacker to synthesize a pointer to arbitrary space, including pointing directly at the return address, bypassing canary protection.
