Subscribe to Grim's Projects        RSS Feed

Staggering Error

Icon Leave Comment
I'm ashamed to admit that Mimesis v2.15 and many of the versions before were all broken and error prone. The worst part is I was blissfully ignorant of the problem. The breakdown of the code is as follows:

Mimesis files are essentially commented PHP files.
All Mimesis files thusly begin with <?php /* (open comment) and terminate with */?> (close comment).
This is done so that if someone types in the URL of one of the Mimesis files, the PHP engine will display a blank page.
It's possible that some value that's entered into the database could contain a '*/' within it, which would close the comments. The user could then enter malicious PHP code to destroy the database from within.
The string '*/' is therefore substituted with the bytes x1A32.
This however introduces that someone may insert x1A32 into one of the values, and thus an improper replacement could occur.
So, anywhere there is a character x1A it is substituted with x1A30, signifying that a character x1A can now only be preceded by a character of my choosing, this is how the delimeters were created.

It is also what created an error that could only be described as catastrophic. Not codewise, but a failure of algorithm on my part. Mimesis would use offsets and lengths as packed byte integers. What I somehow forgot to take into acccount was the fact that x1A substitutions could take place, and a packed integer could easily take the form of x1A1A1A1A. This meant that whenever I tried to retrieve precisely 4 bytes (one of the integers) I could be producing an error. If a substitution took place on any one of the bytes that make up the integer, then I would be missing data. Those pieces of missing data could easily become very volatile.

In v3.0 I've compensated for this expansion by padding all packed integers to an 8-byte length. So even if a substitution does take place, once I retrieve the data and then perform the desubstitution, the unpack function will yield the proper integer value.

An unpack('N', 'some 4 byte string') produces the same results as an unpack('N', 'some 8 byte string') because it only concerns itself with the first 4 bytes. The packed integer data can only ever fluctuate between 4 and 8 bytes due to substitution.

I'm sure that this occurred to me at some point, but since I was thinking about so many things at one time it must've drifted out of my mind and never reentered. Somehow in coding v3.0 I had an epiphany moment about it, AND it was further confirmed by someone who actually wrote back to me with a problem they had. Once I looked at their files there were x1A substitutions all over the place.

Thus, I've had to declare all previous versions broken. Not bugged, just broken, blatantly due to my oversight. It was a very disheartening realization. The only silver lining is that now I know about it and can fix it. I feel like I'm performing a massive factory recall at this point. : shakes head in shame :

0 Comments On This Entry