From rkeith at securityfocus.com Wed Apr 6 11:51:02 2011 From: rkeith at securityfocus.com (rkeith) Date: Wed, 06 Apr 2011 10:51:02 -0600 Subject: [VIM] Joomla Media Local File Inclusion In-Reply-To: References: Message-ID: <4D9C99F6.30800@securityfocus.com> Hey George, Sorry for the delay, was on vaca. I agree, looking at the source of that file, it has always just been a series of class definitions, calling it directly would do nothing. Since May 2010, that file also has protections against calling it directly. Calling this not a vuln, and retiring the BID. -Rob On 03/30/2011 04:57 AM, George A. Theall wrote: > Bugtraq 47043 looks questionable to me. There's no list of versions affected or explanation of the vulnerability other than the PoC: > > http://www.example.com/[path]/components/com_media/helpers/media.php?file=[LFI]%00 > > And while Joomla includes the component in its distribution file in many versions (it doesn't in Joomla 1.0.15, the only version from the 1.0.x series > I checked), the supposedly affected file is nothing more than a class file. It doesn't include / require any other files nor have calls to include() > or require() or its variants. At least in Joomla versions 1.5.22, 1.6.1 (both current), 1.5.12, or 1.5.5. > > Any thoughts, Rob? > > > George From jericho at attrition.org Sat Apr 16 02:34:49 2011 From: jericho at attrition.org (security curmudgeon) Date: Sat, 16 Apr 2011 02:34:49 -0500 (CDT) Subject: [VIM] recent ZDI advisories and "coordinated" In-Reply-To: References: Message-ID: Hi ZDI, Your recent change in disclosure policy has you releasing advisories after a set amount of time, even if a vendor has not provided a patch. However, it seems that you are still using your advisory templates without updating them. Specifically, you are still calling these "coordinated disclosures" when they don't seem to be. As an example: http://zerodayinitiative.com/advisories/ZDI-11-044/ 2011-02-07 - Coordinated public release of advisory Patched April 12, 2011 http://www.microsoft.com/technet/security/Bulletin/MS11-022.mspx That is a two month window when there was no vendor patch available. This is not the generally accepted definition of "coordinated". Could you please clarify? Brian OSVDB.org From jericho at attrition.org Tue Apr 19 15:58:31 2011 From: jericho at attrition.org (security curmudgeon) Date: Tue, 19 Apr 2011 15:58:31 -0500 (CDT) Subject: [VIM] PolarSSL / OpenSSL Message-ID: A recent vulnerability was reported in PolarSSL: http://www.cl.cam.ac.uk/~rja14/Papers/psandqs.pdf http://polarssl.org/trac/wiki/SecurityAdvisory201101 OSVDB 70945, Secunia 43595 Testing by some of the folks at my day job suggests that there really isn't a vulnerability here. Per the research types, "this attack can not work in the real world: while the server may accept a weak DH key, the client is supposed to validate the signature of the server's DH key, so a 3rd party may not implement the attack described [in the advisory]." Further, it was noted that the Nessus plugin (53360) fired on an OpenSSL installation. This lead them to poke around and found that OpenSSL, when compiled in FIPS mode, has this weakness. This information was also made public on the Nessus discussion forum (https://discussions.nessus.org/message/10302#10302). Interestingly enough, the non-FIPS DH implementation does not have the issue, as it validates the key it receives. OSVDB has created 71845 to track the OpenSSL issue. From theall at tenable.com Tue Apr 26 08:30:25 2011 From: theall at tenable.com (George A. Theall) Date: Tue, 26 Apr 2011 09:30:25 -0400 Subject: [VIM] AT-TFTP Server v1.8 Remote Denial of Service Vulnerability Message-ID: <1E3E8862-0746-4700-B5C9-B620FEB2B7CB@tenable.com> Has anyone looked at the report of a DoS in AT-TFTP v1.8 server that SecPod Research published and SecurityFocus covers with BID 47561? Version 1.8 is rather old, and there have been at least two other reports of issues in it: - Luigi Auriemma reported a directory traversal as well as a buffer overflow vulnerability in it back in 2004: http://aluigi.altervista.org/adv/attftp-adv.txt (BID 11584). - Pr0T3cT10n re-reported the directory traversal vulnerability in 1.8 in 2010 (EDB-ID 15438 / BID 44711). And s/he specifically gave as a PoC a GET request for '../../../boot.ini'. - Liu Qixu reported a (very similar?) buffer overflow that can be triggered with a long file name in GET or PUT requests in v1.9 in 2006: http://www.securityfocus.com/archive/1/452743/30/0/threaded (BID 21320) The PoC in SecPod's advisory is: data ='\x00\x01\x2e\x2e\x2f\x2e\x2e\x2f\x2e\x2e\x2f\x62\x6f\x6f' +\ '\x74\x2e\x69\x6e\x69\x00\x6e\x65\x74\x61\x73\x63\x69\x69\x00' I don't see anything there that would overflow a buffer. Instead, it decodes to a GET request for '../../../boot.ini' in NETASCII mode, nearly identical to what Pr0T3cT10n had used in his report and very similar to what Luigi Auriemma had. Thus, it makes me wonder if SecPod posted the wrong exploit. Thoughts? George -- theall at tenablesecurity.com