Skip to main content

Did I find a bug in PHP"s `crypt()`?



I think I may have found a bug in PHP's crypt() function under Windows.





However : I recognize that it's probably my fault . PHP is used by millions and worked on by thousands; my code is used by tens and worked on by me. (This argument is best explained on Coding Horror .)





So I'm asking for help: show me my fault. I've been trying to find it for a few days now, with no luck.





The setup





I'm using a Windows server installation with Apache 2.2.14 (Win32) and PHP 5.3.2. My development box runs Windows XP Professional; the 'production' server (this is an intranet setup) runs Windows Storage Server 2003. The problem happens on both.





I don't see anything in php.ini related to crypt() , but will happily answer questions about my config.





The problem





Several scripts in my PHP app occasionally hang: the page sits there on 'waiting for localhost' and never finishes. Each of these scripts uses crypt to hash a user's password before storing it in the database, or, in the case of the login page, to hash the entered password before comparing it to the version stored in the database.





Since the login page is the simplest, I focused on it for testing. I repeatedly logged in, and found that it would hang maybe 4 out of 10 times.





As an experiment, I changed the login page to use the plain text password and changed my password in the database to its plain text version. The page stopped hanging.





I saw that PHP's latest version lists this bugfix:







Fixed bug #51059 (crypt crashes when invalid salt are [sic] given).







So I created a very simple test script, as follows, using the same salt given in an official example :







$foo = crypt('rasmuslerdorf','r1');

echo $foo;







This page, too, will hang, if I reload it like crazy. I only see it hanging in Chrome, but regardless of browser, the effect on Apache is the same.





Effect on Apache





When these pages hang, Apache's server-status page (which I explained here , regarding a different problem) increments the number of requests being processed and decrements the number of idle workers. The requests being processed almost all have a status of 'Sending Reply,' though sometimes for a moment they will show either 'Reading request' or 'keepalive (read).'





Eventually, Apache may crash . When it does, the Windows crash report looks like this:







szAppName: httpd.exe

szAppVer: 2.2.14.0

szModName: php5ts.dll

szModVer: 5.3.1.0 // OK, this report was before I upgraded to PHP 5.3.2,

// but that didn't fix it

offset: 00a2615







Is it my fault?





I'm tempted to file a bug report to PHP on this. The argument against it is, as stated above, that bugs are nearly always my fault.





However, my argument in favor of 'it's PHP's fault' is:





  1. I'm using Windows, whereas most servers use Linux (I don't get to choose this), so the chances are greater that I've found an edge case



  2. There was recently a bug with crypt() , so maybe it still has issues



  3. I have made the simplest test case I can, and I still have the problem







Can anyone duplicate this? Can you suggest where I've gone wrong? Should I file the bug after all?





Thanks in advance for any help you may give.



Source: Tips4all

Comments

  1. The bugs 51059 (only about passing invalid inputs) or 50947 (not the same code, 5.3 has new algorithms and features implemented in php, on all platforms) are not related to this problem.

    However http://bugs.php.net/bug.php?id=51424 is. I already posted a partial patch there, but it solves most of the possible locks but it is indeed not sufficient. A full fix will be present in the next 5.3 release.

    By the way, it is not windows specific but about the threaded SAPI (windows apache 2.2 for example).

    ReplyDelete
  2. Yes. It's a known bug,

    http://bugs.php.net/bug.php?id=50947

    You can simulate the crypt() result using mcrypt. If you can change your password hash, you should really use hash_hmac(), which is more secure and we have no issues with it On Apache. No experiences on Windows though.

    ReplyDelete
  3. This question has now been viewed 128 times and upvoted 9 times. The only answer I've received says it's a bug, and points to one in the PHP bug database. I don't think it's exactly the same one, but it does seem to validate my diagnosis.

    Therefore, with some hesitation, I have filed a bug report:

    Bug #51666 - Using crypt() makes Apache hang or crash

    Thanks to everyone who has looked at this with me - even if you didn't reply, just knowing that others were considering this with me, and not telling me I'm crazy, has been helpful.

    ReplyDelete

Post a Comment

Popular posts from this blog

[韓日関係] 首相含む大幅な内閣改造の可能性…早ければ来月10日ごろ=韓国

div not scrolling properly with slimScroll plugin

I am using the slimScroll plugin for jQuery by Piotr Rochala Which is a great plugin for nice scrollbars on most browsers but I am stuck because I am using it for a chat box and whenever the user appends new text to the boxit does scroll using the .scrollTop() method however the plugin's scrollbar doesnt scroll with it and when the user wants to look though the chat history it will start scrolling from near the top. I have made a quick demo of my situation http://jsfiddle.net/DY9CT/2/ Does anyone know how to solve this problem?

Why does this javascript based printing cause Safari to refresh the page?

The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex