Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
2014-03-14 20:28 GMT+01:00 Nicholas Lemonias. : > Then that also means that firewalls and IPS systems are worthless. Why > spend so much time protecting the network layers if a user can send any > file of choice to a remote network through http... > No, they are not worthless per se, but of course for an user content publishing service they need to allow file upload over HTTP/s. How far those files are inspected and later processed is another question - and that could lead to a vulnerability that you DIDN'T demonstrate. You just uploaded a .sh file. There's no harm in that as nowhere did you prove that that file is being executed. Similarly (and that has been pointed out in this thread) you could upload a PHP-GIF polyglot file to a J2EE application - no vulnerability in this. Prove something by overwriting a crucial file, tricking other user's browser to execute the file as HTML from an interesting domain (XSS), popping a shell, triggering XXE when the file is processed as XML, anything. Then that is a vulnerability. So far - sorry, it is not, and you've been told it repeatedly. As for the uploaded files being persistent, there is evidence of that. For > instance a remote admin could be tricked to execute some of the uploaded > files (Social Engineering). > Come on, seriously? Social Engineering can make him download this file from pastebin just as well. That's a real stretch. IMHO it is not a security issue. You're uploading a file to some kind of processing queue that does not validate a file type, but nevertheless only processes those files as video - there is NO reason to suspect otherwise, and I'd like to be proven wrong here. Proven as in PoC. ___ 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] Fwd: Google vulnerabilities with PoC
Care to report the same to Dropbox and Pastebin? It's a gold mine, you know... 2014-03-14 20:09 GMT+01:00 Nicholas Lemonias. : > You are wrong, because we do have proof of concepts. If we didn't have > them, then there would be no case. > > But if there are video clips, images demonstrating impact - in which case > arbitrary file uploads (which is a write() call ) to a remote network, then > it is a vulnerability. It is not about the bounty, but rather about not > defying academic literature and widely recognised practise. > > Attacking the arguer, won't make the bug to go away. > > Best, > > Nicholas. > > > On Fri, Mar 14, 2014 at 7:01 PM, Krzysztof Kotowicz < > kkotowicz...@gmail.com> wrote: > >> Nicholas, seriously, just stop. >> >> You have found an 'arbitrary file upload' in a file hosting service and >> claim it is a serious vulnerability. With no proof that your 'arbitrary >> file' is being used anywhere in any context that would lead to code >> execution - on server or client side. You cite OWASP documents (which are >> unrelated to the case), academia papers from 1975 just to find a reason >> it's theoretically serious, not paying any attention to what service you're >> actually attacking and what have you really achieved in that (which is >> demonstrating a filtering weakness at best, low risk). >> >> Everyone on this list so far explains why you're wrong, but you just >> won't stop. So you start throwing out certificates, your academia >> experience and your respected company. Then - name calling everyone else. >> Seriously, it's just a good laugh for most of us. >> >> Dude, please, just because you did not qualify for a bounty, there's no >> point in launching a whole campaign like you are. You're essentially >> following the path of Khalil Shreateh (the guy who posted on Zuckerberg FB >> wall) - he DID find a vuln though. Do you really want that? Go ahead, start >> a crowdsourcing campaign! >> >> >> >> >> >> 2014-03-14 19:40 GMT+01:00 Nicholas Lemonias. > >: >> >>> We have many PoC's including video clips. We may upload for the security >>> world to see. >>> >>> However, this is not the way to treat security vulnerabilities. >>> Attacking the researcher and bringing you friends to do aswell, won't >>> mitigate the problem. >>> >>> >>> >>> ___ >>> 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] Fwd: Google vulnerabilities with PoC
Nicholas, seriously, just stop. You have found an 'arbitrary file upload' in a file hosting service and claim it is a serious vulnerability. With no proof that your 'arbitrary file' is being used anywhere in any context that would lead to code execution - on server or client side. You cite OWASP documents (which are unrelated to the case), academia papers from 1975 just to find a reason it's theoretically serious, not paying any attention to what service you're actually attacking and what have you really achieved in that (which is demonstrating a filtering weakness at best, low risk). Everyone on this list so far explains why you're wrong, but you just won't stop. So you start throwing out certificates, your academia experience and your respected company. Then - name calling everyone else. Seriously, it's just a good laugh for most of us. Dude, please, just because you did not qualify for a bounty, there's no point in launching a whole campaign like you are. You're essentially following the path of Khalil Shreateh (the guy who posted on Zuckerberg FB wall) - he DID find a vuln though. Do you really want that? Go ahead, start a crowdsourcing campaign! 2014-03-14 19:40 GMT+01:00 Nicholas Lemonias. : > We have many PoC's including video clips. We may upload for the security > world to see. > > However, this is not the way to treat security vulnerabilities. Attacking > the researcher and bringing you friends to do aswell, won't mitigate the > problem. > > > > ___ > 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/
[Full-disclosure] [CVE-2014-1403] DOM XSS in EasyXDM 2.4.18
Affected products
=
easyXDM library < 2.4.19 - http://easyxdm.net/wp/
easyXDM is a Javascript library that enables you as a developer to easily
work around the limitation set in place by the Same Origin Policy, in turn
making it easy to communicate and expose javascript API's across domain
boundaries.
Vulnerabilities are fixed in version 2.4.19. All users are advised to
upgrade.
CVE
===
CVE-2014-1403
DOM XSS in name.html location.hash value
Description
---
EasyXDM uses name.html file to bootstrap cross origin communication
between documents. It accepts various parameters in location.hash value,
one of which is the URL of the document to load. Value of this parameter
is not filtered, allowing to pass javascript: URL that may execute
arbitrary Javascript code in context of the domain hosting EasyXDM
installation.
This vulnerability is described in greater details in [1]
Analysis
The root cause of the vulnerability is the following code in name.html
file:
if (location.hash) { // DOM XSS source
if (location.hash.substring(1, 2) === "_") {
var channel, url,
hash = location.href.substring(location.href.indexOf("#") + 3),
indexOf = hash.indexOf(",");
if (indexOf == -1) {
channel = hash;
}
else {
channel = hash.substring(0, indexOf);
url = decodeURIComponent(hash.substring(indexOf + 1));
}
switch (location.hash.substring(2, 3)) {
/...
case "3":
// NameTransport remote
var guest = window.parent.frames[
"easyXDM_" + channel + "_provider"
];
if (!guest) {
throw new Error("unable to reference window");
}
guest.easyXDM.Fn.get(channel)(window.name);
location.href = url + "#_4" + channel + ","; // DOM XSS sink
break;
Part of location hash, under certain conditions, ends up in location.href
assignment, triggering JS execution.
Proof of Concept
http://domain/example/bridge.html"; onload="document.getElementById('f'
).src=
'http://domain/name.html#_3constructor,javascript:alert(document.domain)//'
;">
Credits
===
Vulnerability found by Krzysztof Kotowicz
http://blog.kotowicz.net
Timeline
- 2013-01-xx - Discovery
- 2013-01-10 - Notified project maintainer
- 2013-01-19 - Fixed version release
- 2013-01-31 - Public disclosure
Related links
=
[1]
http://blog.kotowicz.net/2014/01/xssing-with-shakespeare-name-calling.html
___
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] OpenText Exceed On Demand 8 multiple vulnerabilities
Exceed onDemand (EoD) is a dependable managed application access solution
designed for enterprises. It offers pixel perfect drawing, low cost
scalability and trusted security access over any network connection.
Vulnerabilities are present in the current version of the software:
- Product URL:
http://connectivity.opentext.com/products/exceed-ondemand.aspx
- Product Name: **OpenText Exceed OnDemand 8**
- Client version: <= **13.8.3.497**
- Server version: <= **13.8.3.521**
All proof-of-concept codes together with this advisory are hosted at
https://github.com/koto/exceed-mitm
Credits
=
- Slawomir Jasek ``
- Krzysztof Kotowicz ``
Dates
=
- 18.11.2013 - Vendor disclosure
- 21.11.2013 - Additional vulnerabilities found & reported to vendor
- 21.11.2013 - Vendor acknowledges the report, "no further details to
share"
- 06.12.1013 - Query about issue resolution & initial public disclosure
date, vendor ignores
- 16.12.2013 - Full disclosure
Authentication bypass due to protocol downgrade (CVE-2013-6806)
===
Summary
---
If communication between EoD Client and Cluster Manager can be intercepted
and tampered with (e.g. by using ARP poisoning/DNS hijacking/rogue access
point), EoD Client can be forced to using older authentication protocol,
sending out credentials in the clear.
Details
---
Upon connecting to Cluster Manager (TCP port 5500), EoD Client sends 4
bytes: `\x01\x01\x00\x00`, in turn CM responds with 4 bytes, negotiating
the version of the protocol to use. Respond from current CM version is :
`\x0b\x00\x00\x00`. Such a reponse triggers SSL handshake (similar to
STARTSSL mechanism), credentials are then sent in encrypted SSLv3
connection:
Wireshark dump of the beginning of connection:
01 01 00 00
0b 00 00 00
0004 16 03 00 00 6d 01 00 00 69 03 00 52 8d e8 02 cf m...
i..R
0014 88 d3 96 14 f4 a3 7c 47 f3 0d 85 57 58 d6 c9 f7 ..|G
...WX...
0024 18 24 95 15 2e 05 82 27 b7 1e ff 00 00 42 00 3a .$.'
.B.:
0034 00 39 00 38 00 35 00 34 00 33 00 32 00 2f 00 1b .9.8.5.4
.3.2./..
0044 00 1a 00 19 00 18 00 17 00 16 00 15 00 14 00 13
0054 00 12 00 11 00 0a 00 09 00 08 00 07 00 06 00 05
0064 00 04 00 03 c0 19 c0 18 c0 17 c0 16 c0 15 00 ff
0074 01 00..
(16 03 ... bytes initiate SSL connection)
However, if the attacker modifies the response, sending e.g.
`\x01\x01\x00\x00`, client will send credentials in the clear without
establishing SSL connection first:
01 01 00 00
01 01 00 00
0004 11 01 30 0d 08 03 f1 00 00 00 00 00 00 00 00 00 ..0.
0014 00 ff ff 7f 00 00 01 ac 3d 08 08 68 69 6a 61 63
=..hijac
0024 6b 65 64 0a 30 35 31 45 31 45 31 41 32 36 00 01 ked.051E
1E1A26..
Exemplary bytes sent right after the 8-bytes handshake contain user login
and obfuscated password. In standard connection, the same packet is sent
within SSL stream.
We did not try to use Kerberos-based authentication protocol, but the
attack against that will most likely be identical (instead of credentials
the Kerberos ticket will be sent in the clear).
Access conditions
---
Man-in-the-middle attacker
Impact
--
Credentials disclosure, authentication bypass
Proof of Concept
`exceed-downgrade.py` script can be used to test for and exploit that
vulnerability.
Recommendation
-
Do not allow servers to downgrade a protocol in EoD Client communication.
Always require that the credentials are sent in encrypted channel.
More info
-
- CWE-757: Selection of Less-Secure Algorithm During Negotiation
('Algorithm Downgrade') - http://cwe.mitre.org/data/definitions/319.html
- http://en.wikipedia.org/wiki/Opportunistic_encryption
Man in the Middle vulnerability (CVE-2013-6807)
Summary
---
If communication between EoD Client and Cluster Manager can be intercepted
and tampered with (e.g. by using ARP poisoning/DNS hijacking/rogue access
point), communication over SSL channel can be man-in-the-middled due to
using anonymous SSL ciphers.
Details
---
Current version of EoD client when connecting to server side components,
establishes encrypted SSL connection (with the exception of connecting to
EoD Proxy, for which SSL encryption is optional and turned off by default).
In SSL `ClientHello` message EoD client advertises several anonymous
ciphers. In their default configuration EoD servers choose one of
advertis
[Full-disclosure] EasyXDM 2.4.16 multiple vulnerabilities
ot;</a>;,
});
Calling this URL will trigger XSS:
http://jsbin.com/OriDibU/1?#xdm_e=https%3A%2F%2Floscalhost&xdm_c=default7059&xdm_p=6&xdm_s=j%5C%22-alerssst(2)))%7Dcatch(e)%7Balert(document.domain)%7D%2F%2Feheheh
(note - easyxdm.net-based PoC won't work, as version hosted there is
already fixed)
Sites implementing EasyXDM are vulnerable if easyxdm.debug.js is included
anywhere in the codebase in documents that call EasyXDM.Socket() or
EasyXDM.Rpc(). This includes any sites where files from test/example
subdirectory are reachable by URL e.g.
http://easyxdm.net/current/tests/test_transport.html?#xdm_e=https%3A%2F%2Floscalhost&xdm_c=default7059&xdm_p=6&xdm_s=j%5C%22-alerssst(2)))%7Dcatch(e)%7Balert(location)%7D%2F%2Feheheh
Proposed fix
Use sanitizing function on secret parameter
Vulnerability 2: FlashVars parameter injection via URL auth parameters
==
Description
---
When easyXDM creates a HTML code to embed Flash file, it does not properly
URL encode all parameters. By calling the page using easyXDM.Socket() or
easyXDM.Rpc() functions with HTTP auth parameters it is possible to inject
additional FlashVars parameter, modifying behaviour of the Flash file,
allowing to leverage other vulnerabilities.
This vulnerability is described in greater details in [4].
Analysis
When easyXDM creates a HTML code to embed Flash file, it uses wrong regular
expression to parse the domain name and port. The regular expression:
var reURI = /^((http.?:)\/\/([^:\/\s]+)(:\d+)*)/; // returns groups for
protocol (2), domain (3) and port (4)
https://github.com/oyvindkinsey/easyXDM/blob/18c42cff3ab2da68961826786a0c305888bfb6a7/src/Core.js
ignores HTTP authentication parameters.
Domain name and port are later on embedded into HTML forming FlashVars
attribute without proper escaping:
// create the object/embed
var flashVars = "callback=flash_loaded" + domain.replace(/[\-.]/g, "_") +
"&proto=" + global.location.protocol + "&domain=" +
getDomainName(global.location.href) + "&port=" +
getPort(global.location.href) + "&ns=" + namespace;
// #ifdef debug
flashVars += "&log=true";
// #endif
..
swfContainer.innerHTML = ... + ""
https://github.com/oyvindkinsey/easyXDM/blob/18c42cff3ab2da68961826786a0c305888bfb6a7/src/stack/FlashTransport.js
By manipulating URL to include HTTP authentication parameters, attacker is
able to inject additional parameters to flashVars string. However, the only
browser found that does NOT already escape = and & characters in HTTP auth
parameters was Safari, Version 6.0.5 (7536.30.1), OSX/WIN. However, due to
Safari restrictions a phishing warning is displayed before rendering the
page.
Proof of concept
-
// http://jsbin.com/UMUHOgo/1
http://easyxdm.net/current/easyXDM.js"</a>;>
var transport = new easyXDM.Socket({
local: ".",
swf: "<a rel="nofollow" href="http://easyxdm.net/current/easyxdm.swf"">http://easyxdm.net/current/easyxdm.swf"</a>;,
});
Using the following credentials:
user: jsbin.com&log=true&a=
pass:
and loading the following URL in Safari will inject log=true FlashVars
parameter, which, combined with first vulnerability will trigger script
execution in jsbin.com domain.
http://jsbin.com&log=true&a=@
jsbin.com/UMUHOgo/1?#xdm_e=https%3A%2F%2Floscalhost&xdm_c=default7059&xdm_p=6&xdm_s=j%5C%22-alerssst(2)))%7Dcatch(e)%7Balert(document.domain)%7D%2F%2Feheheh
Potentially this can be leveraged to reflected XSS on other browsers that
do not URL encode < and > characters in HTTP auth parameter, however all
current browsers seem to escape that.
Proposed fix
Use encodeURIComponent() function on untrusted domain and port parameters.
Credits
===
Vulnerability found by Krzysztof Kotowicz
http://blog.kotowicz.net
Timeline
2013-08-13 - Discovery
2013-08-27 - Notified project maintainer
2013-09-02 - Fixed in code repository
2013-09-12 - 2.4.18 version with fixes released
2013-09-23 - First public disclosure (blog post)
2013-10-23 - Full public disclosure
Related links
=
[1] http://lcamtuf.blogspot.com/2011/03/other-reason-to-beware-of.html
[2]
http://soroush.secproject.com/blog/2011/03/flash-externalinterface-call-javascript-injection-%E2%80%93-can-make-the-websites-vulnerable-to-xss/
[3]
http://blog.kotowicz.net/2013/09/exploiting-easyxdm-part-1-not-usual.html
[4]
http://blog.kotowicz.net/2013/10/exploiting-easyxdm-part-2-considered.html
___
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] Paypal Core Bug Bounty #3 - Persistent Web Vulnerability
> Successful exploitation of the vulnerability results in persistent session > hijacking (admin), account steal via persistent phishing or > persistent search module web context manipulation. > > Exactly how is the session hijacking/phishing/web content manipulation _persistent_? Just because the payload is _stored_ does not necessarily mean that is it always running. > Proof of Concept: > = > The persistent vulnerability can be exploited by remote attackers with > privileged paypal user account and low required user interaction. > > [...] > > Manually reproduce ... > > 1. Go to the addressbook and switch to add a new contact to adressbook > 2. Include script code (html/js) as username to the addressbook and save > the context > 2. Now, switch to the user search (addressbook) module (other layer) & > click the user contact search to activate > 3. Include the exact name of the username (script code (html/js)) from the > addressbook and press the search button > 4. The context of the other layer from the addressbook will be executed > directly out of the results listing page of the exisiting user contacts > 5. Done! POST REQUEST: method="post" name="searchContact" > > How is THAT a "low user interaction" scenario? IIUC, victim has to manually (no mention of CSRF here) insert a XSS payload into his address book, then search for the payload exactly as inserted (is there a antiCSRF token needed for the search request) and only then is the payload executed. During this scenario user knowingly sees & uses Javascript code twice - that's hardly low interaction. Unless I'm missing something - is there a cross-account action going on where one user manipulates the address book for a second user (e.g. from the same organisation?) Best regards, Krzysztof Kotowicz ___ 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] CodeIgniter <= 2.1.1 xss_clean() Cross Site Scripting filter bypass
This is a security advisory for popular PHP framework - CodeIgniter.
I've found several bypasses in xss sanitization functions in the
framework. These were responsibly disclosed to the vendor and are now
fixed in version 2.1.2. (CVE-2012-1915).
Affected products
==
CodeIgniter <= 2.1.1 PHP framework and all CodeIgniter-based PHP
applications using its built-in XSS filtering mechanism.
CVE
CVE-2012-1915
Introduction
==
CodeIgniter ( http://codeigniter.com) is a powerful PHP framework with
a very small footprint, built for PHP coders who need a simple and
elegant toolkit to create full-featured web applications. CodeIgniter
comes with a Cross Site Scripting Hack prevention filter which can
either run automatically to filter all POST and COOKIE data that is
encountered, or you can run it on a per item basis. Several vectors
bypassing claimed XSS filter protections have been found in 2.1.0
version of the framework. In cooperation with vendor, these have been
fixed in version 2.1.2.
Description
=
XSS filter of CodeIgniter framework is implemented in xss_clean()
function defined in system/core/Security.php file. It uses multiple,
mostly blacklist-oriented methods to detect and remove XSS payloads
from the passed input. As per documentation of the filter (
http://codeigniter.com/user_guide/libraries/security.html ) the filter
is supposed to be run on input passed to the application e.g. before
saving data in the database i.e. it's not an output-escaping, but
input sanitizing filter.
There are multiple ways to bypass the current version of the filters,
exemplary vectors are given below:
// Different attribute separators and invalid regexp detecting tag
closure too early
// Opera 11 svg bypass
http://www.w3.org/2000/svg";
xmlns:xlink="http://www.w3.org/1999/xlink";>
// data: URI with base64 encoding bypass exploiting Firefox
origin-inheritance for data:uris
clickme
in firefox
firefox11
These exemplary bypasses may be used to cause both reflected and
stored XSS attacks depending on the way the application built with
CodeIgniter uses the input filtering mechanism.
Proof of concept
=
Build an application on CodeIgniter 2.1.0:
// application/controllers/xssdemo.php
security->xss_clean($this->input->post('xss'));
$this->load->view('xssdemo', $data);
}
}
// application/views/xssdemo.php
XSS:
Launch http://app-uri/index.php/xssdemo and try above vectors.
Mitigation
Upgrade to CodeIgniter >= 2.1.2. Avoid using xss-clean() function.
It's based on multiple blacklists and will therefore unavoidably be
bypassable in the future. For input filtering, use HTMLPurifier (
http://htmlpurifier.org/ ) instead.
Credits
==
Vulnerability found by Krzysztof Kotowicz
http://blog.kotowicz.net
Timeline
===
2012.03.30 - Notified vendor
2012.04.02 - Vendor response
2012.04.03 - 2012.04.10 - Fixes coordinated with vendor
2012.06.29 - v 2.1.2 released with fixes included
2012.07.19 - Public disclosure
___
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] Trigerring Java code from a SVG image
Kind of. You can still do some stuff from in Opera. http://kotowicz.net/opera/ On Wed, May 16, 2012 at 12:25 PM, Dan Kaminsky wrote: > Anything from in any browser? > > > On Wed, May 16, 2012 at 2:25 AM, Michele Orru > wrote: >> >> Mario Heiderich did a lot of research on that, he found so many bugs >> that allowed >> to embed Javascript in SVG images. >> >> Nice stuff Nick btw, >> >> Cheers >> antisnatchor >> >> On Wed, May 16, 2012 at 10:13 AM, Dan Kaminsky wrote: >> > Yeah, there's a bunch of wild stuff in SVG. The browsers ignore most of >> > it, >> > AFAIK. I think Firefox is the only browser to even consider >> > ForeignObjects >> > (which let you throw HTML back into SVG). >> > >> > Probably the most interesting SVG thing is how they either do or don't >> > have >> > script access, depending on whether or not they're loaded as 's. >> > It >> > would be problematic indeed if could suddenly render >> > script! >> > >> > >> > On Tue, May 15, 2012 at 5:07 AM, Nicolas Grégoire >> > wrote: >> >> >> >> Hello, >> >> >> >> SVG is a XML-based file format for static or animated images. Some SVG >> >> specifications (like SVG 1.1 and SVG Tiny 1.2) allow to trigger some >> >> Java code when the SVG file is opened. >> >> >> >> Given that I had to look at these features for a customer, I developed >> >> some PoC codes which are now available online: >> >> http://www.agarri.fr/docs/batik-evil.svg >> >> http://www.agarri.fr/docs/batik-evil.jar >> >> >> >> I published a more detailed article on my blog: >> >> http://www.agarri.fr/blog/ >> >> >> >> Regards, >> >> Nicolas Grégoire / @Agarri_FR >> >> >> >> ___ >> >> 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/ >> >> >> >> -- >> /antisnatchor > > > > ___ > 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/
