Bugtraq mailing list archives
Re: Security Hole in Netscape Enterprise Server 3.0
From: mfrederick () PHOENIX USWEB COM (Matthew Frederick)
Date: Fri, 24 Apr 1998 09:45:00 -0700
This problem has been around in "Livewire" since its inception. We solved it more securely by putting the actual web file in a protected directory above the website's directory. It makes testing a bit more of a pain (relative URL's have to be mucked with) but it's certainly more secure than renaming the file. The problem with the default setup (and the renaming system) is that the .web file lies in a publicly-readable directory. Put it somewhere where the OS can protect it instead. We really panicked when we first realized this -- we had, of course, database usernames and passwords in the .web file! [BTW, please note that I don't subscribe to BugTraq -- I received this through another source who was just passing it along to me.] ----------------------------------------------------------------- Matthew Frederick USWeb Corporation Director of Technology Phoenix Office Associate Partner mfrederick () phoenix usweb com ----------------------------------------------------------------- USWeb Corporation A Strategic Partner for the Information Age
-----Original Message----- From: Bugtraq List [mailto:BUGTRAQ () NETSPACE ORG]On Behalf Of Daragh Malone Sent: Friday, April 24, 1998 4:48 AM To: BUGTRAQ () NETSPACE ORG Subject: Security Hole in Netscape Enterprise Server 3.0 Hi All, I don't know if there is a patch for this, or if this is already well known, but here it is. A simple workaround follows. Problem: Livewire Applications are downloadable. (Passwords are unencrypted) Platform: DEC UNIX 4.0D (possibly all Unixes/NT) Description: Livewire applications are basically server-side Javascript applications that behave similiar to Active Server Pages. The main difference is that Livewire applications are compiled to a proprietary byte executable that contains all the pages in the application. These applications are generated with .web extensions. In their own example, the game hangman is accessed as http://www.myserver.com/hangman/ and the application is hangman.web. So accessing http://www.myserver.com/hangman/hangman.web will download the application to your browser. The second problem lies in the fact that all the pages are readable, and that database username/passwords are unencrypted, unless specifically encrypted in your application. The two problems combined can compromise security. This problem occurs regardless of Web directory permissions from a server level. Quick Workaround: Rename the .web application to something cryptic like G6r$79k9.web and make sure that the directory it's in isn't a document directory. Rant: I verified this problem on a few Internet sites, which leads to the question: If you verify a web security problem (remember .. at the end of Active Server Pages) is this technically illegal. If anyone knows if this problem has been fixes I'd really appreciate it. Thanks, D.Malone.
Current thread:
- More Microsoft debri Lloyd Vancil (Apr 23)
- <Possible follow-ups>
- Re: More Microsoft debri Michael Howard (Apr 23)
- Re: More Microsoft debri pedward () WEBCOM COM (Apr 23)
- Re: More Microsoft debri James E. Robinson, III (Apr 23)
- Another Frontpage Bug, with promiscuous ScriptAliases pedward () WEBCOM COM (Apr 23)
- Flaw in HTTP-Authentication in O'Reilly Website Pro BarKode (Apr 23)
- Re: Another Frontpage Bug, with promiscuous ScriptAliases Marc Slemko (Apr 23)
- How to exploit AlephOne by JP of AntiOnline F0RMiCA (Apr 24)
- Security Hole in Netscape Enterprise Server 3.0 Daragh Malone (Apr 24)
- Re: Security Hole in Netscape Enterprise Server 3.0 Matthew Frederick (Apr 24)
- How to exploit mudge by AlephOne by JP AntiOnline Dr. Mudge (Apr 24)
- Re: How to exploit mudge by AlephOne by JP AntiOnline Aleph One (Apr 24)
- Re: More Microsoft debri pedward () WEBCOM COM (Apr 23)