[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] fgets bug in mhbuildsbr.c
From: |
David E. West |
Subject: |
Re: [Nmh-workers] fgets bug in mhbuildsbr.c |
Date: |
Thu, 12 May 2005 09:55:44 -0400 |
Hello,
I messed up when attempting to attach the test ZIP file in my previous email.
I accidently used the unpatched version of mhbuild when composing the message
and I didn't inspect it before sending. Also it has come to my attention that
it is common practice for spam blockers to block attached ZIP files anyway, so
below is the ZIP file, in text, base64 encoded.
----[foo.zip]------------------------------------------------------------------
UEsDBBQACQAIAKpVqzLoDk59IQAAABcAAAAHABUAZm9vLnR4dFVUCQADfxqCQn8agkJVeAQA
6QPpA3Ih/EQsZyYd36SqvvRW7jDOV+/eKW/vUXRcOpnxTcB4plBLBwjoDk59IQAAABcAAABQ
SwECFwMUAAkACACqVasy6A5OfSEAAAAXAAAABwANAAAAAAABAAAAoIEAAAAAZm9vLnR4dFVU
BQADfxqCQlV4AABQSwUGAAAAAAEAAQBCAAAAawAAAAAA
-------------------------------------------------------------------------------
There is a command line utility called "base64" that can be used to convert
this back into binary. For example, concatenate the above into one long string
and run the following:
-------------------------------------------------------------------------------
$ echo -n "UEsDBBQACQ . . . awAAAAAA" | base64 -d > foo.zip
-------------------------------------------------------------------------------
The md5 of the resulting binary should be "7a093565d1474332174bd6e884429d51".
Also any 8-bit binary string that is less than 256 bytes long and has only
7-bit characters before the first occupance of a 0x00 character would work.
And the string could be longer than 256 bytes. This pattern would have to be
repeated for each block of 255 bytes in the file. (This is the size of the
temporary buffer into which the fgets call stores file data before the 8/7 bit
determination has been made.) The trick to this bug is that the probability of
it occurring approaches 0, exponentially, based upon the number of 255-byte
blocks there are in the file. When your entire file fits within a single
block, then the probability is much higher, because the detection code only
gets one shot at it. But for large binary files, it is highly unlikely that
that a false negative would occur.
David E. West