[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Gordon Henderson wrote:
On Wed, 7 Oct 2009, tom wrote:Michael Mortimore wrote:On Tue, 06 Oct 2009 10:10:02 +0100, tom <tompotts@xxxxxxxxxxxxxxxxxxxx> wrote:What it does like like to me is a really complicated problem that no-one in computing has ever solved - well everyone other than MS has actually solved it - its called buffer overflow!http://www.theregister.co.uk/2009/10/05/fraudulent_paypay_certificate_published/ Tom te tom te tom"The certificate is the latest to target a weakness that causes browsers, email clients, and other SSL-enabled apps to ignore all text following the \ and 0 characters, which are used to denote the end of a string of characters in C-based languages" Apparently we can't use C to handle windows file paths or numbers as text.I don't think this is as simple as a buffer overflow...When a compiler reads a C source file, it looks for special characters - escaped by the backslash character. \0 in a string means to the C compiler "translate this into byte value 0" often refered to as NUL (as opposed to NULL) C uses the NUL character as a string terminator.
I really hope that they're not compiling on the fly in a security program!
Thats essentially buffer overflow 'backwards' - same absolutely amateur inadequate programming except that wouldn't cause a problem as reading would stop at the NUL byte and the injected code would be ignored. A buffer overflow normally belongs to saying a string is x long and then hoping that the code reads in x+n with n the injected code overwriting the next bit of 'real' code, the code re-starts from x and runs the overwritten code from n. The description given looks like a badly described buffer overflow in the hope that 3 year old coders wont fall about laughing and pointing fingers , or spin.From what I understand here, the C program (or whatever it is) is readingthe characters in, and also doing the escaping and storing them character by character into a buffer somewhere - however it's stored a NUL byte so any subsequent code accessing the string in that buffer has a truncated version of the data, and I think it's the truncated data that's causing the issue.
But its the fact they cant fix it that is so worrying. Tom te tom te tom
Gordon
-- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html