[Full-Disclosure] DoS protection in N-Tiered Web Apps?
Okay, so I asked about this in another thread, but it wasn't really picked up, and I don't want to let it go. There is a fairly serious (and obvious) risk of Denial of Service in many web applications that rely on back-end databases. As a previous message stated, on many web apps, small HTTP requests can result in very CPU intensive queries taking place on the back-end database. In addition, large numbers of HTTP requests can "clog the pipe" between the web logic and the database server, resulting in large backlogs of queries, and possibly even license exhaustion. This is no big surprise, though it might be difficult to stop. Maybe there should be a new name - "asymmetrical data query warfare" or something? (j/k) The solutions I am aware of include establishing protection at the front end (requiring authentication, for example) and using fast hardware and software, and load balancing to accommodate the load. There are other options, too, but they all seem to have pros and cons. However, it seems that a more graceful solution would be to build in some kind of "gatekeeping" logic into the web application itself. For example, creating a state table such that each individual IP address, session or user ID could only monopolize a single thread between the web app and the database server. At least in this way, you could actually guarantee some SLA parameters a little bit better than hoping for the best. TCP/IP QoS wouldn't seem appropriate here, and the database probably isn't smart enough to know about sessions, so it would seem that this would *have* to happen at the application level. So, my question is, how are people dealing with this problem, if at all? Does anyone know of example code that would perform this function? Or another way to accomplish this same goal at a reasonable cost? I'll be the first to admit that my own knowledge is lacking here, which is why I am asking. Maybe this is already built into several platforms and I just never heard about it. Thanks, Mark Lachniet ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Web Application DoS
> +---+ > | Web Application Denial of Service | > +---+ > There is a denial of service condition not in a specific software > product but in several web based applications. > The idea is to make a rather small HTTP request and get a big amount > of data back from the HTTP daemon. Ummm... Duh... BUT, it does raise an interesting problem from a design and testing point of view. I do a lot of web application tests, many of them with automated tools like SPI. In most cases, it is very easy to crash web apps that rely on a database back end. In fact, it's a big problem when it comes to testing production servers. Most small to medium web sites just don't seem to take 15+ query threads at a time very well, especially when you are doing complicated queries (10+ variables, etc.) It is trivially easy to find (for example) a URL request that takes a long time for the query to return (say, 10 seconds or more) and then hammer it with a zillion requests using a simple script. Not only can the database server platform get choked up with requests that it cannot service, but in some cases you can use up all of your licenses too. You might also use such a technique to mess up some logging systems if you are lucky (ie, if it logs audit data to a database). This problem is made worse by the fact that many folks don't use stand-alone database servers for just their web applications, and instead get one "big" database, and use it for a variety of purposes. In this case, you could likely crash more than just the one web app. If it were an IP network issue, I'd say to do some QoS, but is there a good design equivalent of this commonly in use for n-tiered web applications? (for example, building into the web application some logic that maintains a state table of requests, and ensures that single source IP doesn't get more than 1 database lookup thread, or something similar). If there is some good example code for something like this, I'd love to share it with my customers. This subject might also be a good addition to the OWASP guide, which (while and excellent piece of work) doesn't seem to cover much in the way of Denial of Service prevention as far as I know. Thanks, Mark Lachniet ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] WiFi question
Okay, enough people commented on this that I had to dig out my documentation. FWIW, this is what my co-worked documented. My previous summary was not totally accurate. This was discovered by one of my co-workers, not myself. -snip From: [EMAIL PROTECTED] (name withheld to protect against spam) Subject: Some Occupancy Sensors May Cause WiFi Interference So what interferes with 802.11b/g wireless? So far the list seems to be short; microwaves, 2.4 GHz cordless telephones, existing WiFi or Bluetooth equipment.. nuclear reactors!? Now add some occupancy sensors to the list. Specifically, Hubbell MyTech 24KHz ceiling mount sensors, manufactured about ten years ago. I've attached a picture of a newer model; the one that I had problems with is shaped more like a square. They're used to turn lights on and off when people enter large rooms and to regulate heating and air conditioning. 24KHz doesn't sound like WiFi right? Most wireless devices have emissions at some multiple of their operating frequency, in this case 10x. This is called a harmonic frequency and normally these emissions are filtered out. Ten years ago there wasn't much going on with the unlicensed ISM band so my best guess is that the 2.4 GHz harmonic was not filtered out to save costs. I first observed the interference using our Surveyor software although Surveyor did not detect any wireless devices. Curiously, NetStumbler detected an infinitely increasing number of wireless MAC address on an invisible SSID, all operating on channel 10. If I place the NetStumbler tool next to one of the sensors, the SNR goes off the charts every time I wave my hand in front of the sensor. A new random MAC address often times pops up. The MAC addresses aren't registered with any specific manufacturer. They start out with 02:00 and are random for the remaining characters. It might be that NetStumbler is attempting to treat the interference as an actual WiFi device. Anyways, it's something to look out for! -snip Mark Lachniet ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] WiFi question
Could also be RF interference. One of my coworkers tracked down a particularly interesting problem with motion sensor lights. Turns out the motion sensors worked at the 240mhz range, which has resonance at 2.4ghz, or something like that. Hence every time the motion sensor worked, it would spew what the wardriving (site survey) apps thought was a zillion different access points with widely varying MAC addresses. I would have though it was a FAKEAP program also. I would assume the same could happen with other interference. Having a common SSID would seem to indicate this is not the problem, but just thought I'd mention it. Mark Lachniet > -Original Message- > From: KF_lists [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 17, 2004 10:21 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [Full-Disclosure] WiFi question > > fake ap > http://bsdvault.net/bsdfap.txt > http://www.blackalchemy.to/project/fakeap/ > -KF > > > [EMAIL PROTECTED] wrote: > > List, > > > > I'm an expert in nothing so when I saw this I had to ask, > as Im sure > > theres someone out there that is a WiFi expert. > > > > Google has found no answer so here goes. > > > > Last night we saw a new access point appear. No problems > its an ad-hoc > > network so its someone's machine with XP on configured for > their home > > W-LAN probably. Running Netstumbler shows more on it though. > > > > You get 2 Access Points showing this ESSID for a few > seconds. Then you > > get a 3rd, then a 4rth. Then the first two drop off, this > repeats forever. > > Always using a different MAC address when a new AP appears. The APs > > are all WEP enabled (which I cant crack cos I dont have the > savvy or > > the tools :) ) and this goes on forever. > > > > The MACs are all from different pools (i.e. assigned to different > > manufacturers) so the only conclusion is that they are all > spoofed MACs. > > > > I have walked around the office and as far as I can tell its coming > > from this office (the IT dept), basing that assumption on > signal strength. > > > > Anyone seen any tools that do this? I would love a little > hand-held > > gadget that would help me find it (like the scanner in Alien!) > > > > Answers on a post card :) > > > > Colin. > > > > > > > > > > > > > ** > > > > > > This e-mail is confidential and may contain privileged > information. > > If you are not the addressee or if you have received the e-mail in > > error, it may be unlawful for you to read, copy, > distribute, disclose > > or otherwise use the information which it contains. Under these > > circumstances, please notify us immediately by returning > this mail to > > '[EMAIL PROTECTED]' and deleting this e-mail from your system. > > > > Any views expressed by an individual within this e-mail do not > > necessarily reflect the views of Cadbury Schweppes Plc or its > > subsidiaries. Cadbury Schweppes Plc will not be bound by any > > agreement entered into as a result of this email, unless > its intention is clearly evidenced in the body of the email. > > Whilst we have taken reasonable steps to ensure that this > e-mail and > > attachments are free from viruses, recipients are advised > to subject > > this mail to their own virus checking, in keeping with good > computing > > practice. Please note that email received by Cadbury > Schweppes Plc or > > its subsidiaries may be monitored in accordance with the > prevailing law in the United Kingdom. > > > > > ** > > > > > > ___ > > Full-Disclosure - We believe in it. > > Charter: http://lists.netsys.com/full-disclosure-charter.html > > > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Imaging Operating Systems
Any reason not to just use Ghost? Also, some people use VMWARE, and make a "clean" VMWARE image, copy it, load the suspicious stuff, and then delete it afterwards. If you have your virtual network interfaces disabled, it may be a fairly safe sandbox to work in. Mark Lachniet > -Original Message- > From: Michael Schaefer [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 26, 2004 2:55 PM > To: Full-Disclosure > Subject: [Full-Disclosure] Imaging Operating Systems > > Hi all > > We are building a Windows test system, to try out tool bars, > spy ware, malware and trojans on. > > Once we learn what we need to know, we obviously want to get > rid of the junk quickly and cleanly. > > I keep hearing suggestions about having a "clean image" to > transfer onto the computer. > > Can anyone send some details? > > Is there an official Microsoft way to do this? > > Is some sort of over the network OS installation script in order here? > > Are there other vendors that do a better job? > > Thanks > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] E-mail spoofing countermeasures (Was: Backdoor not recognized by Kaspersky)
RE: Accepting mail from spoofed hosts This is really a very simple idea, and a hundred people smarter than me must have thought of it, but I have to wonder if yet another layer of e-mail security might not be in order as well - don't all email systems have a unique message ID on them? Sendmail certainly does. Why not set up some kind of system where the recipient email server does a kind of challenge-response to the originating domain, kind of like IDENT. Here the recipient is the recipient.com mail server, and has a MX record for recipient.com and sender is the sender.com mail server and has a MX record for sender.com Recipient ---> Sender : I got a message from [EMAIL PROTECTED] - is it a legit user? Sender ---> Recipient : Yes, that's one of my users Recipient ---> Sender : Do you have a record of email ID QF2341ASZF for this user? Sender ---> Recipient : Yes, that user sent the email Recipient ---> Sender : Thanks, party on Wayne (email accepted) Sender ---> Recipient : Party on Garth (super, thanks for asking) You might combine the first two dialogs in one, ie, "do you have message ID QF2341ASZF from user [EMAIL PROTECTED]" and provide non-descriptive error messages, so people couldn't easily harvest email addresses ala SMTP VRFY. Of course on the down side, you'd have to use your email server, with legit MX record as your smart host for all users (may be a hassle for home offices and POP clients, maybe requiring outgoing SMTP auth, but that's easy right?) Add to that a good RBL system, and you could cut down a boatload of spam. Mark Lachniet -Original Message- From: Aditya, ALD [Aditya Lalit Deshmukh] [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 1:06 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Full-Disclosure] Backdoor not recognized by Kaspersky > The zip's contents can > be seen without the password, just not unpacked...no cracking it required. now winrar has a option to encrypt file names with a password, me thinks pkzip with the 64 bit compression also has that feature... how are we going to deal with this ? by stopping all the compressed mail at the email gateway ? we do have one solutions: all the mail headers are spoofed so just stop accepting mail from spoofed host, this should solve your spam problem also > You should be blocking executables by policy anyway, yes? that is always being done by the all the people in this day and age, only now we seem to forget to add the compressed file format that are encrypted so that their file contects cannot be seen ? -aditya Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com) ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] 03-02-04 XSS Bug in NetScreen-SA 5000 Series of SSL VPN appliance
TITLE: 03-02-04 XSS Bug in NetScreen-SA 5000 Series of SSL VPN appliance SUMMARY Cross Site Scripting bug in the 'delhomepage.cgi' CGI binary in the Netscreen NetScreen-SA 5000 Series SSL VPN appliance. DETAILS There exists a cross-site scripting bug in 'row' parameter of the 'delhomepage.cgi' CGI binary. This bug was discovered on an appliance known as an "A5030-Clustered pair" running firmware version 3.3 Patch 1 (build 4797). The vulnerability may exist in other versions. This issue may result in the theft of credentials such as session cookies, allow hostile client-side scripts to run with unintended access privileges, or provide a means for a "phishing" attack. For more detailed descriptions of Cross Site Scripting and its implications, please refer to whitepapers such as: http://www.cgisecurity.com/articles/xss-faq.shtml http://www.spidynamics.com/whitepapers/SPIcross-sitescripting.pdf The ‘delhomepage.cgi’ is accessible only by authenticated users. WORKAROUND Upgrade to the patched version of IVE software. Contact Netscreen support for details. ORIGINATOR The issue was discovered by Mark Lachniet of Analysts International [lachniet -=at=- analysts.com] during a security analysis of the web application interface of the device. Analysts International's security team provides a variety of security services and can be reached at [SecurityServices -=at=- analysts.com]. MAINTAINER The maintainer of the Netscreen IVE SSL VPN Appliance is the Netscreen Corporation [http://www.netscreen.com]. The following information about security at Netscreen is taken from the Security Center web page at: http://www.netscreen.com/services/security/index.jsp "Please report any potential or real instances of a security vulnerability (with any NetScreen product or service) to the NetScreen Security Alert Team at [EMAIL PROTECTED] . For immediate assistance, TAC is available 24 hours a day by calling 1-877-NETSCREEN." VENDOR RESPONSE In the opinion of the author, the Netscreen corporation responded quickly and efficiently to this issue, and clearly takes the security of their prodcuts seriously. Netscreen should be commended for their prompt and professional handling of the issue. DATE OF CONTACT 2/6/2004 - Sent E-Mail to Sriram Ramachandran [SRamachandran -=at=- netscreen.com] and received response. Immediately discussed issue via. conference call. The bug was confirmed by the Netscreen staff. 2/7/2004 - Draft advisory sent to Netscreen support staff 2/9/2004 - Ongoing dialog with Netscreen on issue 2/11/2004 - Ongoing dialog with Netscreen on issue 2/18/2004 - Ongoing dialog with Netscreen on issue 2/23/2004 - Ongoing dialog with Netscreen on issue 2/25/2004 - Advisory updated based on vendor response 3/02/2004 - Final advisory released
RE: [Full-Disclosure] Openssl proof of concept code? / Neoteris
Good idea.. I will look at that approach. This is, BTW, more or less what the Nessus ssltest.nasl does - it has its own built-in cert and offers it up without solicitation. If the server takes it (don't know about parsing it) it will flag it as vulnerable. If it doesn't take it, it calls it good. That doesn't actually address the "what if" of what happens if you actually *do* need a valid client cert to hit the page - in this event, you get a false positive hit because it will take the client cert anyway. One thing I did (perhaps naively) try was to use openssl to generate a PEM with funky data (a lot of [EMAIL PROTECTED] type stuff in all the fields). I then took that PEM and manually replaced chunks of valid cert info with random data with VI to make the certificate even LESS likely to work. I then used that cert with STUNNEL and connected to the target device with netcat, and manually issued some HTTP GET commands. Strangely, it worked like a charm, and even established a valid SSL session with my very broken cert. Granted, thats not exactly broken ASN.1 encoding, but its awfully broken as far as certs go. I'm amazed it could set up an SSL connection with the server with a corrupt cert like that. Thank you very much for taking the time to write out that verbose description. The example server-side messages will be helpful. Mark Lachniet -Original Message- From: petard [mailto:[EMAIL PROTECTED] Sent: Thursday, January 15, 2004 3:31 PM To: Lachniet, Mark Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Michael Iseyemi Subject: Re: [Full-Disclosure] Openssl proof of concept code? / Neoteris On Wed, Jan 14, 2004 at 04:34:53PM -0500, Lachniet, Mark wrote: > I did search packetstorm (as always) prior to posting, but came up short. I also spent a lot of time googling the usual suspects. There was some older gobbles openssl code but nothing that seemed to be appropriate to the most recent issues. Its possible I missed something, but I would think someone would have pointed out my error by now if that were the case. > > FWIW, since posting I have not received a single positive lead on an OpenSSL PoC at all. There are plenty of folks who have one, but they aren't talkin' Hence, I think there are still some products out there that are vulnerable, vendors who aren't fixing it, and a small subset of individuals with the ability to exploit it. Not exactly a great recipe for risk management IMO. > > One device that I'm particularly interested in getting more information on is the Neoteris SSL VPN appliance. It fingerprints as Apache 1.3.26 or thereabouts, and has SSL support, so I am guessing that it is running the OpenSSL code base. Yet, I don't see them listed in any of the advisories. It could be a "silent patch" but it could still be vulnerable. Anyone know? > This isn't as good as ./ready-to-run PoC code, but it may help you just the same... I've caught out a few products this way myself. First, modify a copy of openssl such that it sends a client certificate regardless of whether the server requests one. This is a one-line modification and should be trivial if you understand the client-server SSL handshake. Then configure your server such that it does not request client certificates. Generate a throw-away self-signed client certificate and key, and drop them into a PEM file. Using a standalone openssl application built against your modified openssl tree, connect to the server in question. For example: openssl s_client -connect host:443 -cert throwawayclientcert.pem Carefully observe the error that results from this connection. Also look in the server logs for messages similar to: depth=0 /CN=tiny-client/C=US/O=throwaway-pki verify error:num=20:unable to get local issuer certificate verify return:1 which indicate an attempt to parse a client certificate... the server should not try to parse certificates it doesn't request. This is the reason the ASN.1 parser bugs affect so many servers. Here's an example of my modified client running against a vulnerable (0.9.7b) server: $ apps/openssl s_client -connect localhost:4433 -cert client.pem CONNECTED(0003) depth=0 /CN=tiny/C=US/O=throwaway-pki verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /CN=tiny/C=US/O=throwaway-pki verify error:num=27:certificate not trusted verify return:1 depth=0 /CN=tiny/C=US/O=throwaway-pki verify error:num=21:unable to verify the first certificate verify return:1 !!! s3_clnt.c [326] Sending a client cert even though the server didn't ask for one! 2312:error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected message: s3_pkt.c:1052:SSL alert number 10 2312:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226: $ By contrast, here it is running against a patched (0.9.7c) server: $ apps/openssl.exe s_client -connect l
[Full-Disclosure] Openssl proof of concept code? / Neoteris
I did search packetstorm (as always) prior to posting, but came up short. I also spent a lot of time googling the usual suspects. There was some older gobbles openssl code but nothing that seemed to be appropriate to the most recent issues. Its possible I missed something, but I would think someone would have pointed out my error by now if that were the case. FWIW, since posting I have not received a single positive lead on an OpenSSL PoC at all. There are plenty of folks who have one, but they aren't talkin' Hence, I think there are still some products out there that are vulnerable, vendors who aren't fixing it, and a small subset of individuals with the ability to exploit it. Not exactly a great recipe for risk management IMO. One device that I'm particularly interested in getting more information on is the Neoteris SSL VPN appliance. It fingerprints as Apache 1.3.26 or thereabouts, and has SSL support, so I am guessing that it is running the OpenSSL code base. Yet, I don't see them listed in any of the advisories. It could be a "silent patch" but it could still be vulnerable. Anyone know? Mark Lachniet -Original Message- From: Joe Fox [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 14, 2004 4:00 PM To: [EMAIL PROTECTED] Cc: Michael Iseyemi Subject: Re: [Full-Disclosure] Re: Openssl proof of concept code? Michael -- If that's the case, then why even mention anything? Unless there is an openssl exploit that you can disclose. Mark -- Checkout http://www.packetstormsecurity.nl and search for openssl. I believe that you should be able to find some proof of concept code there. Joe On Wed, 2004-01-14 at 14:29, Michael Iseyemi wrote: > Mark, > > There actually is a succesful demo of this exploit > that I am aware of. I'm however not at liberty to > divulge this as it is a littlebit convoluted and also > includes integration testing and efforts between > several components of a PKI. > > Thanks, > Michael > > -- "Lachniet, Mark" <[EMAIL PROTECTED]> > wrote: > Please excuse the cross-post, and please > forgive me > > if I am missing > > something that I should have found through > > conventional sources. > > > > A few months ago, there were issues with the openssl > > code base, as noted > > on bugtraq and in the following URLs: > > http://www.openssl.org/news/secadv_20031104.txt and > > http://www.openssl.org/news/secadv_20030930.txt. It > > was stated that > > these flaws were found using a test suite from NISCC > > (www.niscc.gov.uk). > > However, this toolkit is apparently not publicly > > available (you need to > > be a SSL developer?), and I find no record of a > > proof of concept test > > for this vulnerability. Given that a large number > > of vendors use this > > code base in their products it is no surprise that > > there are a lot of > > products that needed updates. However, I'm not > > convinced that every > > vendor has actually "come clean" about their > > vulnerability to these > > problems. > > > > Is anyone aware of a reasonable way for an analyst > > to definitively > > demonstrate if the vulnerabilities exist in a > > particular product? Since > > some of the bugs deal with bad client certificates, > > some might be as > > easy as getting a copy of a "bad" client certificate > > and connecting to > > the server using a program such as stunnel, but I > > have yet to see > > anything about this. Alternately, has anyone > > written a good program to > > remotely identify what SSL codebase is in use, other > > than looking for it > > in HTTP server headers? Nessus' ssltest.nasl can > > allegedly distinguish > > between a openssl and MS CryptoAPI or Novell, but > > this isn't really > > enough in my opinion. If conventional tools (i.e. > > Nessus and other > > scanners) can't really fingerprint it, how might one > > go a little further > > and determine this from a "black box" perspective? > > I understand that > > with a good deal of development time and effort, > > this can probably be > > done, but this is probably not realistic for most > > organizations to do on > > their own. > > > > Its been a while now, and responsible vendors should > > have already issued > > patches. Also, since there is no proof of concept, > > that I am aware of > > anyway, it seems to me that there is still some > > exposure from these bugs > > that people may not be aware of. It would be nice &
[Full-Disclosure] Openssl proof of concept code?
Please excuse the cross-post, and please forgive me if I am missing something that I should have found through conventional sources. A few months ago, there were issues with the openssl code base, as noted on bugtraq and in the following URLs: http://www.openssl.org/news/secadv_20031104.txt and http://www.openssl.org/news/secadv_20030930.txt. It was stated that these flaws were found using a test suite from NISCC (www.niscc.gov.uk). However, this toolkit is apparently not publicly available (you need to be a SSL developer?), and I find no record of a proof of concept test for this vulnerability. Given that a large number of vendors use this code base in their products it is no surprise that there are a lot of products that needed updates. However, I'm not convinced that every vendor has actually "come clean" about their vulnerability to these problems. Is anyone aware of a reasonable way for an analyst to definitively demonstrate if the vulnerabilities exist in a particular product? Since some of the bugs deal with bad client certificates, some might be as easy as getting a copy of a "bad" client certificate and connecting to the server using a program such as stunnel, but I have yet to see anything about this. Alternately, has anyone written a good program to remotely identify what SSL codebase is in use, other than looking for it in HTTP server headers? Nessus' ssltest.nasl can allegedly distinguish between a openssl and MS CryptoAPI or Novell, but this isn't really enough in my opinion. If conventional tools (i.e. Nessus and other scanners) can't really fingerprint it, how might one go a little further and determine this from a "black box" perspective? I understand that with a good deal of development time and effort, this can probably be done, but this is probably not realistic for most organizations to do on their own. Its been a while now, and responsible vendors should have already issued patches. Also, since there is no proof of concept, that I am aware of anyway, it seems to me that there is still some exposure from these bugs that people may not be aware of. It would be nice to have a test so that people could better gauge their exposure. Can anyone offer a reasonable solution to this problem? Thanks, Mark Lachniet ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
