Slashdot Mirror


Buffer Overflow in MySQL

maedls.at writes "Here is a short description of the Vulnerability:Passwords of MySQL users are stored in the "User" table, part of the "mysql" database, specifically in the "Password" field. In MySQL 4.0.x and 3.23.x, these passwords are hashed and stored as a 16 characters long hexadecimal value, specifically in the "Password" field. Unfortunately, a function involved in password checking misses correct bounds checking. By filling a "Password" field a value wider than 16 characters, a buffer overflow will occur. For details and proof of concept see: http://lists.netsys.com/pipermail/full-disclosure/ 2003-September/009819.html"

1 of 43 comments (clear)

  1. How is still possible? by Anonymous Coward · · Score: 3, Interesting

    In advance: You can mod me down to Flamebait, but I personally think my question is very interesting.

    Buffer overflows have been known for decades, and lots of programs exist to automatically search for them. And it's not that difficult either for someone who knows nothing about programming, to enter very large values in some fields, and see if a "Segmentation Fault" occurs.

    My question here is, why are these buffer overflows still so prevalent? Is it because programmers are lazy? Too lazy to scan the source code with automated scanners to find buffer overflows? Knowing that MySQL is a very crucial program, that's just begging to be exploited, why did no one (else) care to search for buffer overflows before the source code was released? Or is there a deeper problem here?