Hi! On Mar 14, Maarten LITMAATH wrote: > Sergei Golubchik wrote: > > >On Mar 12, Maarten LITMAATH wrote: > > > >>>Description: > >> > >>MySQL (e.g. version 4.0.10-gamma) does not check for buffer overflows > >>when formatting error messages: the code just assumes that no message > >>will ever be larger than SC_MAXWIDTH (256), ERRMSGSIZE (SC_MAXWIDTH) > >>or MYSQL_ERRMSG_SIZE (200). This has been observed to lead to memory > >>corruption when the client e.g. tries to redefine a key with a name > >>whose length is of order 200 (yes, that _is_ a realistic use case for > >>computer-handled keys). > >> > >Nope. Fails for me. > >Error message gets truncated, no overflow. > > OK, let me give a bit more information. I am using MySQL through a > server (the Globus RLS, if you care about that), which does all the > SQL statements. I did some stress testing of that server, trying to > break it, e.g. by supplying "ridiculously" long names for keys, which > caused it to corrupt its own memory and/or crash. Debugging that, > I ultimately came to the MySQL client code that it uses, and found > that it _evidently_ does not check for overflows in error messages. > In the debugger I clearly saw the code scribbling beyond the end of > an error message buffer, overwriting adjacent fields in some struct. > I then patched various routines dealing with error messages (also in > MyODBC) and my problem went away. > > I got truncated error messages too, but _after_ they had overflowed... > Furthermore, whenever such overflow happens, the damage depends on the > layout of the data segment or stack, so your program may survive, > or _seem_ to survive, having corrupted its own memory. > > Please download the diffs and have a look at them: > > http://litmaath.home.cern.ch/litmaath/MyODBC-MySQL-patches/mysql-4.0.10-gamma-ml-diffs.tgz
Ok, I took a look at this. (btw, this was not a diff at all, but rather tarball of new and old files. Having a real unified diff would make your changes MUCH easier to understand). Though your changes looked innocent - that is they most probably could do no harm - I failed to understand when they'll do any good. You replaced a set of checks for buffer overflow by some other set of checks, which looked equivalent to the old one. Please, show at least one single test case where old code gets buffer overflow. Regards, Sergei -- MySQL Development Team __ ___ ___ ____ __ / |/ /_ __/ __/ __ \/ / Sergei Golubchik <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/ /_/ /_/\_, /___/\___\_\___/ Osnabrueck, Germany <___/ --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
