|
|
|
|
|
|
by st_goliath
1328 days ago
|
|
|
> the seventh byte past the buffer is then zeroed/set to the null terminator. I wonder if and how this is exploitable. Well, looking at the upstream code, the original value is saved away before zeroing it out and then unconditionally restored after running crypt. If sudo is single threaded and crypt() doesn't malloc() anything, I don't think that can be exploited. Worst case would be a segfault if the password was somehow close enough to a page boundary. |
|
|
glibc malloc() should be aligned to 2*sizeof(size_t), so strup("")[x] on 64-bit systems (with 16-byte alignment) can never crash or overlap another object where x<16
On 32-bit systems and with other mallocs you could potentially be reaching another page (like I think you are imagining) or trashing some bookkeeping bits which might crash free() but I cannot yet see how you would induce that, nor convince myself it cannot be done without spending more time thinking about it (something I'm reluctant to do with my afternoon)