Date: Fri, 11 Sep 2015 12:29:14 -0500 From: JimF <jfoug@....net> To: john-dev@...ts.openwall.com Subject: Re: auditing our use of FMT_* flags On 9/11/2015 12:10 PM, Solar Designer wrote: > Oh, it's clear now. Thanks. I can not make assurances that my code has caught all of the formats which have this bug. Also, I can not assure that all of the formats which I have listing that they have a problem actually do have a problem (i.e. no assurance that there are not false positives, until we look at all of them). However, this logic 'has' caught a pretty large number of them. I just could not think of any 'safe' way of automatically finding more of them short of blindly smashing case of things which 'look' like hex, only to have all sorts of false errors being shown. However, NOW that the 2 'acceptable' checks which are !valid() or split($c)!=$c being allowed, 'may' make a blind hex smashing check work, and possibly could also show where valid itself is too promiscuous. So that actually may be a good direction to take (I have not tested that theory out). It all boils down to ability to 'catch more' vs time wasted tracking down 'false failures' or having to write a large white-list. However, once we get all of the formats 'fixed' (or fixed and whitelisted), we may actually want to turn some of these extreme checks on in a default manner (or at least a manner we use on our CI build bots). That would force all new formats to be written correctly from the start, proper valid() and proper split() if they use hex encoding. However, there are a LOT of formats which have to be corrected prior to getting to the point of making this logic be the default logic. And each format does have to be approached properly. Some SHOULD adjust valid(), so that only specific hashes would be allowed. Other hashes should have a split that unifies the layout. Even others should adjust both of these functions. So it is not always a 10 minute trivial change.
Powered by blists - more mailing lists