[EMAIL PROTECTED] (Michal Zalewski) writes: > I noticed that Slashdot has a nasty bug, which, I imagine is a > fault of Slashcode. On certain occassions, you can find a very > interesting Referer string for some visitiors of pages mentioned > on this site.
> "http://slashdot.org/?unickname=dXXg&passwd=rXXXX3"; Slashdot, and its software Slash, do offer a URL with which users can log in directly. It is optional. On the pages we offer it, it is clearly marked as "totally insecure, but very convenient." (I am one of the coders of the Slash project, http://slashcode.com/ .) After trading emails with Mr. Zalewski and others who expressed interest in this issue, I have reached some conclusions about this. Short version: There was a misunderstanding in the original post. While we will be making minor changes to our code to improve security, we do not accept responsibility for the one example of a valid password that Mr. Zalewski provided. The other MD5's and passwords found in his referrer log (and others') are all invalid. Detailed version: For the software that Slashdot has used for the past two years, we do not believe any correct passwords or MD5'd passwords have been leaked in referrer logs even using the "totally insecure" option we offer, and we believe that the odds of any accounts having been compromised from this option are fairly low. The odds are not zero, but then -- this is a feature that we advertise as "totally insecure." Most important point: Slash and Slashdot *do* redirect users who log in with the "totally insecure" link. On successful login using the link we provide, the user is immediately sent a 302 Redirect to a URL that does not include the username and password. Our code has done this since at least version 1.0.0 (March 2000). Note that the redirect applies only for *successful* logins using the link *we provide*. Mr. Zalewski provided some examples from his referrer logs of Slashdot users. However, in all but one case, these were unsuccessful logins. The usernames were presumably correct, but in each case the passwords -- actually MD5'd passwords -- were wrong. The site referrer logs he mentioned do contain listings of MD5's and passwords, but all of them are invalid. Obviously, this is not a great thing. A user will be in trouble if he or she: (a) reuses a nickname on other sites, (b) reuses passwords on other sites, (c) uses a dictionary-attackable password on Slashdot (so our MD5 could be reversed), (d) bookmarks the "totally insecure" link (in which case, again, the user pretty much knew what to expect), (e) later changes the password, and (f) continues to use the bookmark to access Slashdot even though it no longer logs in. What we are seeing in referrer logs are users who fit (d), (e) and (f), but we do not know how many also fit conditions (a), (b) and (c). The code changes we have made are as follows: (1) even unsuccessful login attempts, using the URL format we provide, will be given a 302 Redirect to remove the username and (wrong) password from the query string; (2) Slash sites which use our code now must set a variable if they want to offer the "totally insecure" option to their users; by default, for current sites and new sites, it will be off. These code changes are in CVS now and will be on slashdot.org soon. The one example which Mr. Zawelski provided to me which does *not* fit the pattern described above happens to be the one which he quoted in his original post to bugtraq and vulnwatch. This redacted URL: http://slashdot.org/?unickname=dXXg&passwd=rXXXX3 actually contains a username and password which are correct. However, Slash never outputs a URL of that format to the user, and never has in the past (back to version 0.2, July 1998). This user has created his or her own URL. It does not even log in successfully. It is as meaningless to our code as if the user appended a credit card number in the query string. Slash cannot control what sensitive data people type into URLs that they make up themselves, and we don't take responsibility for that data appearing in referrer logs. The user with that username and password has been contacted and asked to change his or her password and bookmark. Please address security issues regarding Slash or Slashdot to <[EMAIL PROTECTED]>. This address is at the top of the slashcode.com homepage and can also be found by clicking the "bugs" link on the slashdot.org homepage.
