From Bugtraq.
-j
Approved-By: aleph1@SECURITYFOCUS.COM Delivered-To: bugtraq@lists.securityfocus.com Delivered-To: BUGTRAQ@SECURITYFOCUS.COM X-Hate: Where do you want to go to die? Date: Thu, 30 Mar 2000 10:16:08 +0200 Reply-To: Michal Zalewski lcamtuf@DIONE.IDS.PL Sender: Bugtraq List BUGTRAQ@SECURITYFOCUS.COM From: Michal Zalewski lcamtuf@DIONE.IDS.PL Subject: NetCache/NetApp Release 3.4 X-To: BUGTRAQ@SECURITYFOCUS.COM To: BUGTRAQ@SECURITYFOCUS.COM
NetCache by Network Appliance (www.netapp.com) is one of the most popular heavy-duty commercial proxy/cache application. In fact, it's rather poorly written. We can't see the source code, but, some side effects instead. There's a lot of them, but I'll try to focus on something called 'internal requests' - requests that access proxy itself and are handled specially.
For example, by connecting to proxy server and sending 'GET http://proxy_server_itself:8080/disk_objects/help', we'll (usually) get error message with this URL and a few stupid characters appended at the end of it. It won't happen if you specify anything after 'help' - so I believe it's something like broken sscanf() used to determine which help object user wants. But that's not the point. Try appending slash and approx 10k of 'A' letters to our request. In case of any other request treated as 'external', it might result only in error message. But in this case, with something around 9850 characters, our connection to proxy server is immediately dropped... sounds familiar? I believe it's an overflow.
Another way to access it (urm, I mean, cause crash) is something like: 'GET disk_object://xx/AAAAA...'. Btw. I'm wondering there's anything interesting available to download this way? There are some pictures, disk_object://xx/help/graphics/help.gif and so on, but I haven't access to NetCache box to check what else is inside... Aaaah, almost forgotten! Any file within disk_object hierarchy might be downloaded as-is by appending '/' to URL - for example, 'disk_object://xx/help/graphics/help.gif/' will return text/plain dump of this GIF. This means, NetCache fails to classify this file, so if there's any script or other special object, it won't be recognized as something 'special'?
--
Just to make everything clear - I haven't shell access to running NetCache box, so I cannot verify I'm absolutely right - eg. if there's anything interesting within disk_objects or what extactly happens, but I think there's absolutely something wrong, and there's no excuse for poor, even commercial, code.
#include <stddiscl.h> // Standard Disclaimer applies
Michal Zalewski * [lcamtuf@ags.pl] <=> [AGS WAN SYSADM] [dione.ids.pl SYSADM] <-> [http://lcamtuf.na.export.pl] [+48 22 551 45 93] [+48 603 110 160] bash$ :(){ :|:&};: =-----=> God is real, unless declared integer. <=-----=
From: Michal Zalewski lcamtuf@DIONE.IDS.PL But in this case, with something around 9850 characters, our connection to proxy server is immediately dropped... sounds familiar? I believe it's an overflow.
Nope. Our default window size is about 8K. The socket is probably about the same. If an error closes the socket before you've finished writing, you're likely to see a write error rather than a polite error message.
Another way to access it (urm, I mean, cause crash) is something like: 'GET disk_object://xx/AAAAA...'. Btw. I'm wondering there's anything interesting available to download this way?
Static gifs and docs. Perhaps it would have been better to protect them against unauthorized access, but since anyone who wants them can get them by purchasing a cache and we don't view the docs as a profit center, it didn't strike us as a high priority.
Aaaah, almost forgotten! Any file within disk_object hierarchy might be downloaded as-is by appending '/' to URL - for example, 'disk_object://xx/help/graphics/help.gif/' will return text/plain dump of this GIF. This means, NetCache fails to classify this file, so if there's any script or other special object, it won't be recognized as something 'special'?
If we had any secret scripts accessible as disk_objects, this might be a problem. Since we don't, this is merely a clever way to confuse your browser.
Just to make everything clear - I haven't shell access to running NetCache box, so I cannot verify I'm absolutely right - eg. if there's anything interesting within disk_objects or what extactly happens, but I think there's absolutely something wrong, and there's no excuse for poor, even commercial, code.
Our code is not perfect, but the absolute opinions expressed are absolutely wrong.
--bob-- Cache breaks, compiling Ash leaves shimmer beneath clouds, Nerf ball strikes face.
Static gifs and docs. Perhaps it would have been better to protect them against unauthorized access, but since anyone who wants them can get them by purchasing a cache and we don't view the docs as a profit center, it didn't strike us as a high priority.
I think any security issue is high priority to fix especially if issue has been posted to bugtrack. It hardly inspires confidence that serious security issues will be dealth with in the correct and proper manner.
If we had any secret scripts accessible as disk_objects, this might be a problem. Since we don't, this is merely a clever way to confuse your browser.
This is joke especially since a simple strings of the code base shows there are undocumented code features.
Colin Johnston SA PSINET UK
In message Pine.GSO.4.05.10003311053290.12018-100000@staff.uk.psi.com, Colin Johnston writes:
I think any security issue is high priority to fix especially if issue has been posted to bugtrack. It hardly inspires confidence that serious security issues will be dealth with in the correct and proper manner.
Let me put it another way. The only things in the disk object directory are static gifs and administration documentation. The only security risk they present is that someone who hasn't purchased a cache can read them. Since the same documents are available on any netcache, anywhere, denying access to them will not improve system security.
[There are no secret scripts].
This is joke especially since a simple strings of the code base shows there are undocumented code features.
There are undocumented features, but there are no scripts in the disk_object directory. I don't know whether there are undocumented documents.
--bob-- Cache breaks, compiling Ash leaves shimmer beneath clouds, Nerf ball strikes face.
Hi, I seem to have found a log rotation bug in NetCache Appliance 4.0 R4 code release. It seems the messages file is not rotating anymore and this is creating huge 2mb+ messages files so when weekly autosupport emails are sent large emails are being produced.
Does anyone know if this is fixed in 4.1R1 code release and if not can it be fixed for the next early code release ??
Thanks
Colin Johnston SA PSINET UK
* Colin Johnston (colinj@uk.psi.com) done spit this rhetoric:
Hi, I seem to have found a log rotation bug in NetCache Appliance 4.0 R4 code release. It seems the messages file is not rotating anymore and this is creating huge 2mb+ messages files so when weekly autosupport emails are sent large emails are being produced.
Howdy Colin!
Are there any messages regarding log rotation being produced when the log should be rotated?
-
Colin Johnston -
Jamie Lawrence -
Jerry Talkington -
Robert English