Comments on: Read This Now! http://blog.dreamhost.com/2007/02/23/read-this-now/ Tales From the Inside! Sun, 22 Nov 2009 23:18:54 +0000 http://wordpress.org/?v=2.8.6 hourly 1 By: Security Issues http://blog.dreamhost.com/2007/02/23/read-this-now/comment-page-1/#comment-72920 Security Issues Mon, 19 Mar 2007 01:20:47 +0000 http://blog.dreamhost.com/2007/02/23/read-this-now/#comment-72920 [...] get access to sensitive files including e.g. passwords. Dallas, one of the founders of DreamHost, explains that the issue is minor, and that it’s up to each customer to secure their files [...] [...] get access to sensitive files including e.g. passwords. Dallas, one of the founders of DreamHost, explains that the issue is minor, and that it’s up to each customer to secure their files [...]

]]> By: Unofficial DreamHost Blog » Blog Archive » Security Issues http://blog.dreamhost.com/2007/02/23/read-this-now/comment-page-1/#comment-67862 Unofficial DreamHost Blog » Blog Archive » Security Issues Wed, 07 Mar 2007 20:58:14 +0000 http://blog.dreamhost.com/2007/02/23/read-this-now/#comment-67862 [...] get access to sensible files including e.g. passwords. Dallas, one of the founders of DreamHost, explains that the issue is minor, and that it’s up to each customer to secure their files [...] [...] get access to sensible files including e.g. passwords. Dallas, one of the founders of DreamHost, explains that the issue is minor, and that it’s up to each customer to secure their files [...]

]]> By: DreamHost Blog » Super Lame Apology http://blog.dreamhost.com/2007/02/23/read-this-now/comment-page-1/#comment-63836 DreamHost Blog » Super Lame Apology Thu, 01 Mar 2007 06:14:58 +0000 http://blog.dreamhost.com/2007/02/23/read-this-now/#comment-63836 [...] We are all really bearry sorry about the extended downtime this Sunday from the planned power outage! [...] [...] We are all really bearry sorry about the extended downtime this Sunday from the planned power outage! [...]

]]> By: Barbara http://blog.dreamhost.com/2007/02/23/read-this-now/comment-page-1/#comment-62891 Barbara Tue, 27 Feb 2007 15:26:34 +0000 http://blog.dreamhost.com/2007/02/23/read-this-now/#comment-62891 Just Great! Now you all are gonna get "hand-held" by dreamhost...and they are gonna raise their prices... just great! Just Great! Now you all are gonna get “hand-held” by dreamhost…and they are gonna raise their prices…

just great!

]]> By: Dallas http://blog.dreamhost.com/2007/02/23/read-this-now/comment-page-1/#comment-62479 Dallas Mon, 26 Feb 2007 20:10:08 +0000 http://blog.dreamhost.com/2007/02/23/read-this-now/#comment-62479 As Jim pointed out, the situation pointed out on that forum thread is not really an issue. We have historically left things relatively open by default to make it easier for customers to have direct access to their other user accounts on the server. Your email is private, though, and has never been open to anyone but you. Any files you do not need to have read by the web server (including config files read by scripts running as your user) can and should be locked down appropriately. We have historically left that task to you. Web files are inherently public as they are on the Internet so that hasn't been a concern for us, and config files with database information should always be locked down. Our one-click installer handles that part for you. That said, this particular question has been brought up enough times that we have decided to change our default permissions on user directories. It's been rolling out little by little to make it easier to rollback if anything unexpected happens. Newly created users have had the newer more restrictive permissions for a week and a half now already. If you are concerned about your own home directory and can't wait until the new setup rolls out to your server, you can contact our support team and we can lock it down for you. As Jim pointed out, the situation pointed out on that forum thread is not really an issue. We have historically left things relatively open by default to make it easier for customers to have direct access to their other user accounts on the server. Your email is private, though, and has never been open to anyone but you. Any files you do not need to have read by the web server (including config files read by scripts running as your user) can and should be locked down appropriately. We have historically left that task to you. Web files are inherently public as they are on the Internet so that hasn’t been a concern for us, and config files with database information should always be locked down. Our one-click installer handles that part for you.

That said, this particular question has been brought up enough times that we have decided to change our default permissions on user directories. It’s been rolling out little by little to make it easier to rollback if anything unexpected happens. Newly created users have had the newer more restrictive permissions for a week and a half now already. If you are concerned about your own home directory and can’t wait until the new setup rolls out to your server, you can contact our support team and we can lock it down for you.

]]> By: S Jain http://blog.dreamhost.com/2007/02/23/read-this-now/comment-page-1/#comment-62407 S Jain Mon, 26 Feb 2007 15:26:19 +0000 http://blog.dreamhost.com/2007/02/23/read-this-now/#comment-62407 @Chris According to the link I posted http://www.webhostingtalk.com/showthread.php?t=582814 ... Dreamhost was notified about security breached before I even posted it. In addition, according to 1 person on that forum, he notified Dreamhost about it in 2005. I have also submitted a ticket but with no response so far in over 15 hours. I would assume something of this importance would get their notice. @Jim Once you access the log folder of someone, you can find out which domains they host and then it is relatively quick to find out their CMS and in turn directory structure. You can use that directory structure to read all the files including config files because I believe the lowest permission they assign is still 664. I haven't seen 660. @Chris
According to the link I posted http://www.webhostingtalk.com/showthread.php?t=582814 … Dreamhost was notified about security breached before I even posted it. In addition, according to 1 person on that forum, he notified Dreamhost about it in 2005.

I have also submitted a ticket but with no response so far in over 15 hours. I would assume something of this importance would get their notice.

@Jim
Once you access the log folder of someone, you can find out which domains they host and then it is relatively quick to find out their CMS and in turn directory structure.

You can use that directory structure to read all the files including config files because I believe the lowest permission they assign is still 664. I haven’t seen 660.

]]> By: carol taylor http://blog.dreamhost.com/2007/02/23/read-this-now/comment-page-1/#comment-62403 carol taylor Mon, 26 Feb 2007 15:14:18 +0000 http://blog.dreamhost.com/2007/02/23/read-this-now/#comment-62403 Catering To Computers is our web host service using you as a server source. We are still experienceing the IMAP email error and we are unable to update our web site as access is denied. This has been going on since last Thursday. Catering To Computers is our web host service using you as a server source. We are still experienceing the IMAP email error and we are unable to update our web site as access is denied. This has been going on since last Thursday.

]]> By: Marcos http://blog.dreamhost.com/2007/02/23/read-this-now/comment-page-1/#comment-62399 Marcos Mon, 26 Feb 2007 15:01:01 +0000 http://blog.dreamhost.com/2007/02/23/read-this-now/#comment-62399 Why my comments are being tagged as spam? Being unhappy is not an option? Why my comments are being tagged as spam? Being unhappy is not an option?

]]> By: Chris http://blog.dreamhost.com/2007/02/23/read-this-now/comment-page-1/#comment-62386 Chris Mon, 26 Feb 2007 14:27:57 +0000 http://blog.dreamhost.com/2007/02/23/read-this-now/#comment-62386 Tactful, real fucking tactful. This guy finds what he believes to be a serious security flaw, and rather than contact Dreamhost to report it, he: 1) assumes "they know they have an insecure setup" 2) posts the alleged security flaw for everyone to see. Get a goddamn clue to fucking moron! Tactful, real fucking tactful.

This guy finds what he believes to be a serious security flaw, and rather than contact Dreamhost to report it, he:

1) assumes “they know they have an insecure setup”
2) posts the alleged security flaw for everyone to see.

Get a goddamn clue to fucking moron!

]]> By: Jim http://blog.dreamhost.com/2007/02/23/read-this-now/comment-page-1/#comment-62196 Jim Mon, 26 Feb 2007 05:22:37 +0000 http://blog.dreamhost.com/2007/02/23/read-this-now/#comment-62196 I see the problem now. That is bad cause people can access and read program files (PHP, Python, Rails, etc.) without being processed and some of those files can have passwords to databases/logins. One fix for this... remove read access to outside (everyone) world from all files/directories in your main directory. Or at least the domain directories. That way unless someone knows you have X CMS installed and knows the file/directory structure of that program, there is less chance of them doing anything. As for things showing up in the logs... There should not be anything important in the logs. Passwords should NOT be passed by GET and should not show up in the url. If a program does use GET to pass important form variables, I would contact the developers or fix it yourself (if possible). I see the problem now. That is bad cause people can access and read program files (PHP, Python, Rails, etc.) without being processed and some of those files can have passwords to databases/logins.

One fix for this… remove read access to outside (everyone) world from all files/directories in your main directory. Or at least the domain directories.

That way unless someone knows you have X CMS installed and knows the file/directory structure of that program, there is less chance of them doing anything.

As for things showing up in the logs… There should not be anything important in the logs. Passwords should NOT be passed by GET and should not show up in the url. If a program does use GET to pass important form variables, I would contact the developers or fix it yourself (if possible).

]]>