> I was bit confused with this link ( > http://www.rstcorp.com/news/bad-crypto-tech.html ), since I am not quite > clear if these guys are just reinventing the wheel, or have found > something new. It turns out that the Windows algorithm used in conjunction with the registry is subtly different from the one used for preference.js files, which has been previously reported. One of the things we were suprised to find is that they are remarkably similar (we had not looked closely at the details of the previous exploit at the time we did the reported analysis). The Windows algorithm is slightly stronger, but still extremely weak. We are in the process of looking at the timing of various events and versions to discover if the new algorithm is the result of a "band aid" solution to the previously reported problem. Previous exploit code like the one you posted and others we have found on the web all only handle the older, weaker version. In addition, the consequences of this flaw in a Windows environment are substantially different, due to the lack of access controls. As we discussed in the technical summary, while there is no perfect solution to this problem, it would take very little work for Netscape to make future exploits of this type much more difficult. The current position of Netscape, that these sorts of vulnerabilities need not be fixed, is in my opinion rather irresponsible. Software companies have a responsibility to make exploiting their software as difficult as possible, _especially_ in cases like this where the cost to do so is similar to, or less than, the cost of using absurdly weak proprietary cryptography. It is Netscape's responsibility to put the bar at as high a level as is feasible and economical. As Avi Rubin, security expert at ATT Labs, pointed out, in this case Netscape needs to run out and get a bar so they can raise it. Tim Hollebeek Reliable Software Technologies
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:21:37 PDT