[Full-disclosure] When is it valid to claim that a vulnerability leads to a remote attack?
A reputable security defect reporting organization is claiming that a Windows program is subject to a remote attack because: * The vulnerable program (call it 'pqrminder') is registered as the 'handler' for files with a specific extension (call it '.pqr'). * If the user downloads a '.pqr' file (or is sent on in the mail and clicks on it), then 'pqrminder' is invoked. * If the file is malformed, then arbitrary code can be executed (buffer overflow). While recognizing that there is a bug here, that does not strike me as being what is normally meant by a 'remote attack'. -- Jonathan Leffler (jleff...@us.ibm.com) STSM, Informix Database Engineering, IBM Information Management 4400 N First St, San Jose, CA 95134-1257 Tel: +1 408-956-2436 Tieline: 475-2436 "I don't suffer from insanity; I enjoy every minute of it!"___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] When is it valid to claim that a vulnerability leads to a remote attack?
Hi Jonathan, IMHO it generally is classified as remote. Some vendors call it "user assisted remote arbitrary code execution" which, in my opinion is just downplaying the issue - there are virtually unlimited means to get somebody or something to open such a file some less assisted but still exploiting the issue at hand. If you want to find common ground with said person, propose the denomination above. This subject is indeed interesting and worth discussing, not sure FD is the best place though. Regards, Thierry JL> A reputable security defect reporting organization is claiming that a JL> Windows program is subject to a remote attack because: JL> * The vulnerable program (call it 'pqrminder') is registered as the JL> 'handler' for files with a specific extension (call it '.pqr'). JL> * If the user downloads a '.pqr' file (or is sent on in the mail and clicks JL> on it), then 'pqrminder' is invoked. JL> * If the file is malformed, then arbitrary code can be executed (buffer JL> overflow). JL> While recognizing that there is a bug here, that does not strike me as JL> being what is normally meant by a 'remote attack'. JL> -- JL> Jonathan Leffler (jleff...@us.ibm.com) JL> STSM, Informix Database Engineering, IBM Information Management JL> 4400 N First St, San Jose, CA 95134-1257 JL> Tel: +1 408-956-2436 Tieline: 475-2436 JL> "I don't suffer from insanity; I enjoy every minute of it!" -- http://blog.zoller.lu Thierry Zoller ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] When is it valid to claim that a vulnerability leads to a remote attack?
On Fri, 09 Oct 2009 12:09:08 +0200, Thierry Zoller said: > IMHO it generally is classified as remote. Some vendors call it > "user assisted remote arbitrary code execution" which, in my opinion > is just downplaying the issue - there are virtually unlimited means to > get somebody or something to open such a file some less assisted but > still exploiting the issue at hand. I concur with Thierry - the fact that one of the steps in the exploit is "get the user to click on it" does *not* mean the vendor can stick their head in the sand and claim it's not an issue. It just means the exploit will require a social engineering step as well as coding. If you think that it's hard to get users to run the program for you, consider that a very large community is making a lot of money sending users e-mail that says "please go to this web page and enter your userid, password, and credit card number so we can take all your money". Of course, they have to do a little work so it looks like it came from the victim's bank... pgpDlVnZEWtki.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] When is it valid to claim that a vulnerability leads to a remote attack?
--On Thursday, October 08, 2009 22:16:01 -0500 Jonathan Leffler wrote: > > A reputable security defect reporting organization is claiming that a Windows > program is subject to a remote attack because: > > * The vulnerable program (call it 'pqrminder') is registered as the 'handler' > for files with a specific extension (call it '.pqr'). > * If the user downloads a '.pqr' file (or is sent on in the mail and clicks > on it), then 'pqrminder' is invoked. > * If the file is malformed, then arbitrary code can be executed (buffer > overflow). > > While recognizing that there is a bug here, that does not strike me as being > what is normally meant by a 'remote attack'. In fact it's very typical of the types of attacks we see every day now. By far the most routinely successful attacks now are initiated through some sort of social engineering trick that requires user interaction to trigger the compromise. If by remote you mean "live interaction by the hacker at the point of attack" (as in a "traditional" hack), then no, it's not a remote attack. I think the more normal undertstanding of remote attack (although it's usually worded remote compromise) is that the result of a successful attack is the opening of a gateway that can lead to additional compromise or complete takeover of a machine. Given the details you've offered, think this qualifies as "potentially leading to a remote compromise" of a machine. The attack begins when the unsuspecting user clicks on a link to either open an attachment or view a webpage or video. In the background the compromise takes place, after which the malicious software "phones home", downloads additional tools, etc. until the host is completely and utterly compromised. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] When is it valid to claim that a vulnerability leads to a remote attack?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 09 Oct 2009 10:24:02 -0400 Paul Schmehl wrote: >--On Thursday, October 08, 2009 22:16:01 -0500 Jonathan Leffler > wrote: > >> >> A reputable security defect reporting organization is claiming >that a Windows >> program is subject to a remote attack because: >> >> * The vulnerable program (call it 'pqrminder') is registered as >the 'handler' >> for files with a specific extension (call it '.pqr'). >> * If the user downloads a '.pqr' file (or is sent on in the mail >and clicks >> on it), then 'pqrminder' is invoked. >> * If the file is malformed, then arbitrary code can be executed >(buffer >> overflow). >> >> While recognizing that there is a bug here, that does not strike >me as being >> what is normally meant by a 'remote attack'. > >In fact it's very typical of the types of attacks we see every day >now. By far >the most routinely successful attacks now are initiated through >some sort of >social engineering trick that requires user interaction to trigger >the >compromise. > >If by remote you mean "live interaction by the hacker at the point >of attack" >(as in a "traditional" hack), then no, it's not a remote attack. >I think the >more normal undertstanding of remote attack (although it's usually >worded >remote compromise) is that the result of a successful attack is >the opening of >a gateway that can lead to additional compromise or complete >takeover of a >machine. Given the details you've offered, think this qualifies >as >"potentially leading to a remote compromise" of a machine. > >The attack begins when the unsuspecting user clicks on a link to >either open an >attachment or view a webpage or video. In the background the >compromise takes >place, after which the malicious software "phones home", downloads >additional >tools, etc. until the host is completely and utterly compromised. > >-- >Paul Schmehl, Senior Infosec Analyst >As if it wasn't already obvious, my opinions >are my own and not those of my employer. >*** >"It is as useless to argue with those who have >renounced the use of reason as to administer >medication to the dead." Thomas Jefferson > >___ >Full-Disclosure - We believe in it. >Charter: http://lists.grok.org.uk/full-disclosure-charter.html >Hosted and sponsored by Secunia - http://secunia.com/ Think Adobe Acrobat, most of the issues had to do with file parsing(JBIG2 comes to mind), and the drive by campaigns exploiting the issue(s) were probably quite successful... elazar -BEGIN PGP SIGNATURE- Charset: UTF8 Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 3.0 wpwEAQECAAYFAkrPdoYACgkQi04xwClgpZjcogP7B3C79Hr+0RJe9z0Ds9qO8ReKJIkB OLfm5QuifgEuz7Z/4mX2k0ZMqGkqJT3rBE2sR82vrTR2vNK0pMnoNxIy/V71MXBmdZqE PpXssC5LBRgWD29jFWeBIC0ORTrBZJ1+lcg3dmx9mYlr3moKk9yE3+GXg5Jds2vZvgDy OUqnnyk= =LCG2 -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] When is it valid to claim that a vulnerability leads to a remote attack?
Hi Dan, DK> There are a substantial number of file formats that are code-execution DK> equivalent with no exploits necessary -- .exe, .com, .bat, etc. You thus DK> can't say that an executed file must not execute code, because there's no DK> way for the user to know whether a file on his desktop is an .exe or DK> something else. Maybe I misunderstand what you are saying but - Isn't the point in this case is that running binary files mapped as executables is not exploiting a vulnerability in a third party application ? I understood that Jonathan was asking whether the exploitation of a file format vulnerabilityin Product X can be categorized as remotely exploitable - even though it is not exposed to the outside and one can only reach arbitrary control by indirect means. I think we can agree that yes, it is remotely exploitable and as such should be categorized as "remote" in Risk/Impactt scoring systems ? Does anybody disagree ? I'd be interested to hear your point of view. DK> The key here is "escalation of privilege". At the point you're launching DK> formats, the privilege has already been granted. If you could dive into this a bit more as I can't follow you here. I frankly don't know any Access control logic where running a format leads to the escalation of a privilege, per se. -- http://blog.zoller.lu Thierry Zoller ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] When is it valid to claim that a vulnerability leads to a remote attack?
> - Original Message - > From: "Thierry Zoller" > To: full-disclosure@lists.grok.org.uk > Cc: valdis.kletni...@vt.edu, "Jonathan Leffler" > Subject: Re: [Full-disclosure] When is it valid to claim that a > vulnerability leads to a remote attack? > Date: Wed, 14 Oct 2009 14:11:50 +0200 Thierry, please fix your clock. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] When is it valid to claim that a vulnerability leads to a remote attack?
Well, why are you relying on Thierry's clock to date your message? Your e-mail client should use your local clock/mail server clock to timestamp messages. --Rohit Patnaik On Sat, Oct 10, 2009 at 10:25 PM, Chris wrote: > >> - Original Message - >> From: "Thierry Zoller" >> To: full-disclosure@lists.grok.org.uk >> Cc: valdis.kletni...@vt.edu, "Jonathan Leffler" >> Subject: Re: [Full-disclosure] When is it valid to claim that a >> vulnerability leads to a remote attack? >> Date: Wed, 14 Oct 2009 14:11:50 +0200 > > > Thierry, please fix your clock. > > > -- > ___ > Surf the Web in a faster, safer and easier way: > Download Opera 9 at http://www.opera.com > > Powered by Outblaze > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] When is it valid to claim that a vulnerability leads to a remote attack?
Unreal. Only on FD could someone be attacked for pointing out a problem. > - Original Message - > From: "Rohit Patnaik" > To: full-disclosure@lists.grok.org.uk > Subject: Re: [Full-disclosure] When is it valid to claim that a > vulnerability leads to a remote attack? > Date: Sat, 10 Oct 2009 22:32:49 -0500 > > > Well, why are you relying on Thierry's clock to date your message? > Your e-mail client should use your local clock/mail server clock to > timestamp messages. > > --Rohit Patnaik > > On Sat, Oct 10, 2009 at 10:25 PM, Chris wrote: > > > >> - Original Message - > >> From: "Thierry Zoller" > >> To: full-disclosure@lists.grok.org.uk > >> Cc: valdis.kletni...@vt.edu, "Jonathan Leffler" > >> Subject: Re: [Full-disclosure] When is it valid to claim that a > >> vulnerability leads to a remote attack? > >> Date: Wed, 14 Oct 2009 14:11:50 +0200 > > > > > > Thierry, please fix your clock. > > > > > > -- > > ___ > > Surf the Web in a faster, safer and easier way: > > Download Opera 9 at http://www.opera.com > > > > Powered by Outblaze > > > > ___ > > Full-Disclosure - We believe in it. > > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > > Hosted and sponsored by Secunia - http://secunia.com/ > > > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] When is it valid to claim that a vulnerability leads to a remote attack?
> I think we can agree that yes, it is remotely exploitable and as such > should be categorized as "remote" in Risk/Impactt scoring systems ? > > Does anybody disagree ? I'd be interested to hear your point of view. Hey Thierry - I hope all is well... I'm happy to include "user assisted remote exploitation" as a "remote" vulnerability in academic conversations, but I don't categorize it as "remote" when assessing overall risk to a particular threat in production environments. Like everyone else, my TMs include impact and skill required to exploit a particular vulnerability; but they also include "likelihood of exploitation." While that may sound like a wildcard metric, I quantify it by applying the internal controls in place that may mitigate a particular attack. In "my" networks (networks I control, design, or consult for) most users couldn't execute [common] exploits even if they wanted to. I won't bore you with the controls I deploy as I'm confident you are well aware of the options one has, but the fact they exist at all place "user assisted remote exploits" in a different category for me when assessing risk. When the propensity for a vulnerability to be exploited lies in a particular user's response to any given trigger, as opposed to any authoritative in-place controls to mitigate exposure, then a model's relevant response options are greatly diminished (IMO). As such, I choose to categorize "remote" exploits as those that may be executed against a given host that is autonomously running a [vulnerable] service that can be connected to by some (any) other network client, device, or service for the purposes of ascertaining overall risk. t ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] When is it valid to claim that a vulnerability leads to a remote attack?
If you classify a remote bug (anything that can be exploited remotely) then you are classifying all bugs (you can use a privilege escalation exploit remotely) I agree with Thor, anything that exploits a remote service (HTTP,FTP Etc..) without any user interaction. On Sun, Oct 11, 2009 at 12:54 AM, Thor (Hammer of God) wrote: > > > > I think we can agree that yes, it is remotely exploitable and as such > > should be categorized as "remote" in Risk/Impactt scoring systems ? > > > > Does anybody disagree ? I'd be interested to hear your point of view. > > Hey Thierry - I hope all is well... > > I'm happy to include "user assisted remote exploitation" as a "remote" > vulnerability in academic conversations, but I don't categorize it as > "remote" when assessing overall risk to a particular threat in production > environments. Like everyone else, my TMs include impact and skill required > to exploit a particular vulnerability; but they also include "likelihood of > exploitation." While that may sound like a wildcard metric, I quantify it > by applying the internal controls in place that may mitigate a particular > attack. In "my" networks (networks I control, design, or consult for) most > users couldn't execute [common] exploits even if they wanted to. I won't > bore you with the controls I deploy as I'm confident you are well aware of > the options one has, but the fact they exist at all place "user assisted > remote exploits" in a different category for me when assessing risk. When > the propensity for a vulnerability to be exploited lies in a particular > user's response to any given > trigger, as opposed to any authoritative in-place controls to mitigate > exposure, then a model's relevant response options are greatly diminished > (IMO). > > As such, I choose to categorize "remote" exploits as those that may be > executed against a given host that is autonomously running a [vulnerable] > service that can be connected to by some (any) other network client, device, > or service for the purposes of ascertaining overall risk. > > t > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > -- http://www.goldwatches.com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] When is it valid to claim that a vulnerability leads to a remote attack?
What are your thoughts on an exploit for a client that connects to a (malicious) service through the network? I certainly wouldn't call it a local attack... On Sun, Oct 11, 2009 at 8:18 PM, James Matthews wrote: > If you classify a remote bug (anything that can be exploited remotely) then > you are classifying all bugs (you can use a privilege escalation exploit > remotely) I agree with Thor, anything that exploits a remote service > (HTTP,FTP Etc..) without any user interaction. > > On Sun, Oct 11, 2009 at 12:54 AM, Thor (Hammer of God) > wrote: >> >> >> > I think we can agree that yes, it is remotely exploitable and as such >> > should be categorized as "remote" in Risk/Impactt scoring systems ? >> > >> > Does anybody disagree ? I'd be interested to hear your point of view. >> >> Hey Thierry - I hope all is well... >> >> I'm happy to include "user assisted remote exploitation" as a "remote" >> vulnerability in academic conversations, but I don't categorize it as >> "remote" when assessing overall risk to a particular threat in production >> environments. Like everyone else, my TMs include impact and skill required >> to exploit a particular vulnerability; but they also include "likelihood of >> exploitation." While that may sound like a wildcard metric, I quantify it >> by applying the internal controls in place that may mitigate a particular >> attack. In "my" networks (networks I control, design, or consult for) most >> users couldn't execute [common] exploits even if they wanted to. I won't >> bore you with the controls I deploy as I'm confident you are well aware of >> the options one has, but the fact they exist at all place "user assisted >> remote exploits" in a different category for me when assessing risk. When >> the propensity for a vulnerability to be exploited lies in a particular >> user's response to any given >> trigger, as opposed to any authoritative in-place controls to mitigate >> exposure, then a model's relevant response options are greatly diminished >> (IMO). >> >> As such, I choose to categorize "remote" exploits as those that may be >> executed against a given host that is autonomously running a [vulnerable] >> service that can be connected to by some (any) other network client, device, >> or service for the purposes of ascertaining overall risk. >> >> t >> >> ___ >> Full-Disclosure - We believe in it. >> Charter: http://lists.grok.org.uk/full-disclosure-charter.html >> Hosted and sponsored by Secunia - http://secunia.com/ > > > > -- > http://www.goldwatches.com > > > > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] When is it valid to claim that a vulnerability leads to a remote attack?
--On October 11, 2009 7:18:33 PM -0500 James Matthews wrote: > If you classify a remote bug (anything that can be exploited remotely) > then you are classifying all bugs (you can use a privilege escalation > exploit remotely) I agree with Thor, anything that exploits a remote > service (HTTP,FTP Etc..) without any user interaction. > My understanding of the classical meaning of "remote exploit" is that the machine can be exploited without the attacker needing to have an account on the box. A local exploit is one that requires that the attacker first obtain access to the box. For example, you can exploit ls on a Linux box to elevate your privileges, if you can first get on the box through ssh or some other method. I have never seen remote exploit definitions require the limitation of no user action. When discussing taxonomy and the usefulness of vulnerability definitions in real world scenarios, it's much more useful to know that something can be exploited without the attacker having access to the box. Certainly a higher priority is placed on resolving those issues than ones where the attacker first has to obtain access. Paul Schmehl, If it isn't already obvious, my opinions are my own and not those of my employer. ** WARNING: Check the headers before replying ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] When is it valid to claim that a vulnerability leads to a remote attack?
I think the classification system as a whole is ultimately based on agenda. Vendors (I presume) don't want things to sound as bad as they may be. Researchers want things to sound as bad as they CAN be. And the rest of the people would like a means by which to measure "urgency" to patch as it relates to cost/benefit, risk/threat, and potential consequences of inaction. So I think it ultimately comes down to a sliding scale of what the person responsible for incident response is comfortable with. To me, I draw the line of a "remote" exploit to "no user or system interaction required" as I've previously stated. You have to make SOME sort of qualification, or else calculated responses become unmanageable. Analysis beyond that (to me) enters you into a model of diminishing returns. By way of example: If you can send an email exploit to an Outlook client that can execute by a preview only, is that remote? I would say no, as a user would have to preview it. If one could exploit the same vulnerability just by it arriving into one's Outlook inbox without preview would it THEN be remote? Again, I would say no, as Outlook would have to be running. And, of course, one would have to be running Outlook in the first place. As a group, I don't think we need to define what "remote" is. That's up to the response team. What you need to do is decide on what you do when YOU classify something as remote, and then take action according to a predefined plan. That is really the advice I have for the OP. Don't look to what other people consider remote; decide for yourself, and plan a course of action accordingly. t > -Original Message- > From: Paul Schmehl [mailto:pschmehl_li...@tx.rr.com] > Sent: Sunday, October 11, 2009 6:25 PM > To: James Matthews; Thor (Hammer of God) > Cc: full-disclosure@lists.grok.org.uk; valdis.kletni...@vt.edu; > Jonathan Leffler > Subject: Re: [Full-disclosure] When is it valid to claim that a > vulnerability leads to a remote attack? > > --On October 11, 2009 7:18:33 PM -0500 James Matthews > wrote: > > > If you classify a remote bug (anything that can be exploited > remotely) > > then you are classifying all bugs (you can use a privilege escalation > > exploit remotely) I agree with Thor, anything that exploits a remote > > service (HTTP,FTP Etc..) without any user interaction. > > > > My understanding of the classical meaning of "remote exploit" is that > the > machine can be exploited without the attacker needing to have an > account > on the box. A local exploit is one that requires that the attacker > first > obtain access to the box. For example, you can exploit ls on a Linux > box > to elevate your privileges, if you can first get on the box through ssh > or > some other method. > > I have never seen remote exploit definitions require the limitation of > no > user action. > > When discussing taxonomy and the usefulness of vulnerability > definitions > in real world scenarios, it's much more useful to know that something > can > be exploited without the attacker having access to the box. Certainly > a > higher priority is placed on resolving those issues than ones where the > attacker first has to obtain access. > > Paul Schmehl, If it isn't already > obvious, my opinions are my own > and not those of my employer. > ** > WARNING: Check the headers before replying ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] When is it valid to claim that a vulnerability leads to a remote attack?
On Sat, 10 Oct 2009 22:32:49 CDT, Rohit Patnaik said: > Well, why are you relying on Thierry's clock to date your message? > Your e-mail client should use your local clock/mail server clock to > timestamp messages. Hint: your e-mail client *can't* timestamp this message, because it has no *clue* when I hit send on this message. Consider that you can't even trust the timestamp on the first Received: header, because I could very well have composed the mail and hit send while offline, and it got posted to a server once I had network connectivity again. The sending MUA is responsible for this, but often an end-user MUA will fail to add a Date: header and the fixup is done at the first mail server, pgpUxWJcgVj72.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
