From coley at mitre.org Thu Sep 1 17:53:55 2005 From: coley at mitre.org (Steven M. Christey) Date: Thu Sep 1 17:54:06 2005 Subject: [VIM] NISCC advisories Message-ID: <200509012153.j81Lrt9H025951@linus.mitre.org> Just a quick note that vuln DB's should make sure to monitor NISCC security advisories. We've missed a couple of them even though they had CVE numbers, but sometimes when I "catch up" there doesn't seem to be an entry in other VDBs. NISCC is not yet using the typical wide distribution channels. I'll save my comments on the use of proprietary document formats that don't support proper copy-and-paste for some other time. - Steve From jericho at attrition.org Thu Sep 1 17:56:00 2005 From: jericho at attrition.org (security curmudgeon) Date: Thu Sep 1 17:56:02 2005 Subject: [VIM] NISCC advisories In-Reply-To: <200509012153.j81Lrt9H025951@linus.mitre.org> References: <200509012153.j81Lrt9H025951@linus.mitre.org> Message-ID: : Just a quick note that vuln DB's should make sure to monitor NISCC : security advisories. We've missed a couple of them even though they had : CVE numbers, but sometimes when I "catch up" there doesn't seem to be an : entry in other VDBs. NISCC is not yet using the typical wide : distribution channels. : : I'll save my comments on the use of proprietary document formats that : don't support proper copy-and-paste for some other time. And linking to second documents for 'vulnerable product matrix' =) I've been watching them as best I can but given how few they seem to release, I tend to forget after a few weeks. I'm also not terribly thrilled over their vague advisories listing 3 CVE candidates and giving no clue what they correspond to, without digging into additional proprietary documents that you and I both love. From jericho at attrition.org Fri Sep 2 07:43:41 2005 From: jericho at attrition.org (security curmudgeon) Date: Fri Sep 2 07:43:43 2005 Subject: [VIM] vendor advisory cut/paste gone bad Message-ID: http://www.trustix.org/errata/2005/0045/ assuming they don't fix it by the time you read.. "The Common Vulnerabilities and Exposures project has assigned the name CAN-2005-2491 to this issue." This is included under vulns for apache, pcre, php4, php, and python =) From jericho at attrition.org Fri Sep 2 07:50:19 2005 From: jericho at attrition.org (security curmudgeon) Date: Fri Sep 2 07:50:26 2005 Subject: [VIM] Typo/error on latest advisory.. Message-ID: http://www.trustix.org/errata/2005/0045/ Under each vulnerability, you list the same CVE candidate. "The Common Vulnerabilities and Exposures project has assigned the name CAN-2005-2491 to this issue." forced ~$ lynx -dump http://www.trustix.org/errata/2005/0045/ | grep 2491 name CAN-2005-2491 to this issue. name CAN-2005-2491 to this issue. name CAN-2005-2491 to this issue. name CAN-2005-2491 to this issue. name CAN-2005-2491 to this issue. forced ~$ lynx -dump http://www.trustix.org/errata/2005/0045/ | grep 2491 | wc -l 5 forced ~$ From jericho at attrition.org Sun Sep 4 14:18:22 2005 From: jericho at attrition.org (security curmudgeon) Date: Sun Sep 4 14:18:25 2005 Subject: [VIM] vendor advisory cut/paste gone bad In-Reply-To: References: Message-ID: : http://www.trustix.org/errata/2005/0045/ : : assuming they don't fix it by the time you read.. : : "The Common Vulnerabilities and Exposures project has assigned the name : CAN-2005-2491 to this issue." : : This is included under vulns for apache, pcre, php4, php, and python =) My mistake! These are all for the pcre issue, thus the same CVE. Since CVE hadn't listed the products out this time, I made a hasty conclusion. =) From coley at mitre.org Wed Sep 7 14:38:27 2005 From: coley at mitre.org (Steven M. Christey) Date: Wed Sep 7 14:39:09 2005 Subject: [VIM] PBLang security forum Message-ID: <200509071838.j87IcRvF005811@linus.mitre.org> FYI, I found a forum where the PBLang developer acknowledges various issues from the past, although the most recent problems aren't listed there: http://pblforum.drmartinus.de/board.php?cat=2&fid=2&s=s - Steve From jericho at attrition.org Tue Sep 13 04:27:47 2005 From: jericho at attrition.org (security curmudgeon) Date: Tue Sep 13 04:27:50 2005 Subject: [VIM] FreeRADIUS mess + drama Message-ID: Little drama between the FreeRADIUS team and SuSE: http://www.freeradius.org/security/20050909-vendor-sec.txt This is the real interesting post. Quoting relevant parts that may be of interest to us, as they directly relate to vulnerability reports and the headaches we suffer as a result. http://www.freeradius.org/security/20050909-response-to-suse.txt [..] The version audited was 1.0.2.5-5. Version 1.0.4 has been out for almost two months now, and would have been a better choice for auditing. [..] By our analysis, the issues Suse raises may be grouped into the following categories: (a) low-impact, non-exploitable externally accessible issues 5.1 (1) ldap escaping (b) low-impact non-exploitable, non-externally accessible issues. 5.4 sql_unixodbc memory allocation error (c) issues exploitable by the RADIUS server administrator 5.9 (1) max_fd 5.11 (2) vradlog, line 135 5.11 (3) vradlog, line 150 5.15 (1) max_fd 5.15 (3) MAX_ENVP not checked (d) Misunderstandings or misreading of the source: 5.1 (2) unavailable LDAP blocking the server 5.3 (1) sql_escape_func 5.3 (2) rlm_sql_authorize, line 747 5.7 (1) check_for_realm, line 209 5.7 (2) check_for_realm, line 210 5.9 (2) arguments to checkrad 5.11 (1) vradlog, line 133 5.12 (1) rad_auth_log 5.12 (2) rad_authenticate line 678 5.13 (2) rad_decode() 5.13 (3) rad_pwdecode() 5.13 (4) rad_tunnel_pwdecode() 5.14 (2) DNS escaping for SQL 5.15 (2) escaping command-line options Out of 21 reported issues, 14 are not real. A false-positive rate of 67% is indicates serious issues with the analysis methods. [..] We have concerns with a message Suse sent to the vendor-sec mailing list. Our response is here: http://www.freeradius.org/security/suse-vendor-sec.txt Shortly after our response, RedHat posted a message on Bugtraq, which led to the following vulnerability listing on Security Focus: http://www.securityfocus.com/bid/14775 The comments under "discuss" say: http://www.securityfocus.com/bid/14775/discuss The first issues are memory handling vulnerabilities. These issues may allow remote attackers to crash affected services, or possibly execute arbitrary machine code in the context of the vulnerable application. FreeRADIUS is also affected by a possible file descriptor leak. This may be exploited to gain access to files that an attacker may not normally have access to. Based on our analysis, both of these comments are, quite simply, false. For the issues found by Suse, there is no possible external exploit vector that crashes the system or allows execution of arbitrary machine code. From coley at linus.mitre.org Tue Sep 13 16:39:00 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue Sep 13 16:40:03 2005 Subject: [VIM] Patches to VegaDNS available (fwd) Message-ID: catching up on old email, sorry if this was already forwarded. ---------- Forwarded message ---------- Date: Sun, 11 Sep 2005 22:29:36 -0700 From: Bill Shupp To: cve@mitre.org Subject: Patches to VegaDNS available Hello, I'm the author of VegaDNS, which was recently reported to contain 2 security flaws: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2610 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2609 I have patched both the stable and development versions, and posted updated versions here: http://vegadns.org Can you add a notation to your advisories that there are updates available? I'll be notifying my mailing lists and Freshmeat as well. Thanks! Bill From coley at mitre.org Tue Sep 20 19:29:36 2005 From: coley at mitre.org (Steven M. Christey) Date: Tue Sep 20 19:31:04 2005 Subject: [VIM] Possible combined Evolution issue(s) Message-ID: <200509202329.j8KNTasn013402@linus.mitre.org> I haven't done extensive research on this, but it appears that some VDB's have combined multiple Evolution issues into a single record. CAN-2005-0806 is for a bug report that originated from: http://bugzilla.ximian.com/show_bug.cgi?id=72609 and covered in several vendor advisories. This is reported for 2.0.3. The bug report is scarce on exploit details. The original report was early February 2005. This appears to have been combined with a full-disclosure post in late Feb 2005: Novell/Ximian Evolution multiple text attachments DoS http://archives.neohapsis.com/archives/fulldisclosure/2005-02/0591.html The discloser appears to be different from the original bug report associated with CAN-2005-0806, and this Full-Disclosure issue appears to involve a large number of attachments, whereas the CAN-2005-0806 seems to involve a single odd article. - Steve From jericho at attrition.org Tue Sep 20 21:20:34 2005 From: jericho at attrition.org (security curmudgeon) Date: Tue Sep 20 21:20:37 2005 Subject: [VIM] man2web mess Message-ID: http://cve.mitre.org/cgi-bin/cvename.cgi?name=2005-2812 man2web allows remote attackers to execute arbitrary commands via -P arguments. BID:14747 URL:http://www.securityfocus.com/bid/14747 BID doesn't reference anything remotely (other than vendor home page) but credits "tracewar". Three exploit URLs and relevant text: http://packetstorm.linuxexposed.com/0509-exploits/dl-mancgi.c Man-cgi/Man2web/ManViewer Remote Command Execution Exploit Exploit coded and bugs found by tracewar of DarkLogic [+] Man2web (ALL VERSIONS) [+] ManViewer (ALL VERSIONS) targets: 0=Man-cgi 1=man2web 2=Man2html http://downloads.securityfocus.com/vulnerabilities/exploits/dl-mancgi.c x86/linux multipie man2web cgi-scripts remote command spawn targets: \n0=man-cgi\n1=man2web\n2=man2html http://www.securiteam.com/exploits/5XP031PGUW.html (same as above) So the confusion comes in: what are the products vs vulnerable scripts? First URL suggests Man2web and ManViewer are two products, and man-cgi, man2web and man2html are the scripts. But it also suggests ManViewer may be a script or product as the first line mentions two scripts and manviewer in the same line: Man-cgi/Man2web/ManViewer Remote Command Execution Exploit [+] ManViewer (ALL VERSIONS) From coley at linus.mitre.org Thu Sep 22 01:04:04 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Thu Sep 22 01:05:45 2005 Subject: [VIM] man2web mess In-Reply-To: References: Message-ID: On Tue, 20 Sep 2005, security curmudgeon wrote: > So the confusion comes in: what are the products vs vulnerable scripts? > > First URL suggests Man2web and ManViewer are two products, and man-cgi, > man2web and man2html are the scripts. But it also suggests ManViewer may > be a script or product as the first line mentions two scripts and > manviewer in the same line: My read is that man2web is the product. from the exploit: x86/linux multipie man2web cgi-scripts remote command spawn the man-cgi, man2web, and man2html "targets" are discriminated based on how the "-P" argument is appended to the /cgi-bin/man-cgi URL, suggesting to me that man-cgi is the binary, but under the hood there are multiple programs that are launched. But then again I just downloaded an old (2003) copy of "man2web" 0.88 and a grep for man2html failed. A grab of "ManViewer" 0.9 from 2000 didn't help much, although it appears to call man2html but there's nothing for man2web. hmmmmmmmmmmmmmm Wonder if this exploit was tested on some custom installation. a mess, indeed... - Steve From coley at mitre.org Thu Sep 22 01:11:26 2005 From: coley at mitre.org (Steven M. Christey) Date: Thu Sep 22 01:13:00 2005 Subject: [VIM] provable vendor ACK for Mall23 issues Message-ID: <200509220511.j8M5BQPf011140@linus.mitre.org> I filled out an online inquiry for a Mall23 issue and got a vendor ack for that, plus another one, within a couple hours, by Dean Higginbotham of Mall23. The relevant issues are: http://systemsecure.org/ssforum/viewtopic.php?t=219 http://systemsecure.org/ssforum/viewtopic.php?t=277 - Steve From jericho at attrition.org Thu Sep 22 01:15:10 2005 From: jericho at attrition.org (security curmudgeon) Date: Thu Sep 22 01:15:13 2005 Subject: [VIM] man2web mess In-Reply-To: References: Message-ID: : the man-cgi, man2web, and man2html "targets" are discriminated based on : how the "-P" argument is appended to the /cgi-bin/man-cgi URL, : suggesting to me that man-cgi is the binary, but under the hood there : are multiple programs that are launched. : : But then again I just downloaded an old (2003) copy of "man2web" 0.88 : and a grep for man2html failed. : : A grab of "ManViewer" 0.9 from 2000 didn't help much, although it : appears to call man2html but there's nothing for man2web. : : hmmmmmmmmmmmmmm : : Wonder if this exploit was tested on some custom installation. : : a mess, indeed... For now I created an entry for each of the possible scripts, but I still can't figure out where 'ManViewer' comes into play beyond the comments of the various exploits. Bleh! From jericho at attrition.org Thu Sep 22 01:23:27 2005 From: jericho at attrition.org (security curmudgeon) Date: Thu Sep 22 01:23:29 2005 Subject: [VIM] Re: [OSVDB Mods] ncompress insecure temporary file creation (fwd) Message-ID: still no reply, yet he has posted advisories to F-D since this mail. ---------- Forwarded message ---------- From: security curmudgeon To: ZATAZ Audits Cc: eromang@zataz.net, Mods Date: Sat, 17 Sep 2005 20:46:30 -0400 (EDT) Subject: Re: [OSVDB Mods] ncompress insecure temporary file creation : ncompress insecure temporary file creation : Vendor: ftp://ftp.leo.org/pub/comp/os/unix/linux/sunsite/utils/compress/ : Advisory: http://www.zataz.net/adviso/ncompress-09052005.txt : : The vulnerability is caused due to temporary file being created : insecurely. This can be exploited via symlink attacks in combination : with a race condition to create and overwrite arbitrary files with the : privileges of the user running the affected script. : Technical details : : ncompress use vulnerable version off zdiff and zcmp. : : Related : : Secunia : http://secunia.com/advisories/13131/ : CVE : CAN-2004-0970 Hi Eric, CAN-2004-0970 covers gzexe, zdiff, and znew, but doesn't make mention of zcmp. Was gzip's zcmp vulnerable and not originally disclosed? Or is this something specific to ncompress? Thanks! Brian OSVDB.org From coley at linus.mitre.org Thu Sep 22 01:33:34 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Thu Sep 22 01:35:09 2005 Subject: [VIM] Re: [OSVDB Mods] ncompress insecure temporary file creation (fwd) In-Reply-To: References: Message-ID: Some Linux folks recently confirmed to me that this was a distinct issue, that the underlying codebases seemed quite different and the names of the affected binaries seem coincidental. So I gave it CAN-2005-2991. I sent Romang an e-mail a couple weeks ago to no response as well, but for an unrelated issue. Maybe his spam filter is too fascist? - Steve From sullo at cirt.net Thu Sep 22 08:34:49 2005 From: sullo at cirt.net (Sullo) Date: Thu Sep 22 08:36:29 2005 Subject: [VIM] man2web mess In-Reply-To: References: Message-ID: <4332A4E9.3000102@cirt.net> security curmudgeon wrote: >: the man-cgi, man2web, and man2html "targets" are discriminated based on >: how the "-P" argument is appended to the /cgi-bin/man-cgi URL, >: suggesting to me that man-cgi is the binary, but under the hood there >: are multiple programs that are launched. >: >: But then again I just downloaded an old (2003) copy of "man2web" 0.88 >: and a grep for man2html failed. >: >: A grab of "ManViewer" 0.9 from 2000 didn't help much, although it >: appears to call man2html but there's nothing for man2web. >: >: hmmmmmmmmmmmmmm >: >: Wonder if this exploit was tested on some custom installation. >: >: a mess, indeed... > >For now I created an entry for each of the possible scripts, but I still >can't figure out where 'ManViewer' comes into play beyond the comments of >the various exploits. > > Yeah, I spent a good hour trying to find those "programs" as part of man-cgi program or stand-alone, and didn't come up with anything. -Sullo -- http://www.cirt.net/ | http://www.osvdb.org/ From jericho at attrition.org Thu Sep 22 23:54:58 2005 From: jericho at attrition.org (security curmudgeon) Date: Thu Sep 22 23:54:59 2005 Subject: [VIM] PBLang security forum In-Reply-To: <200509071838.j87IcRvF005811@linus.mitre.org> References: <200509071838.j87IcRvF005811@linus.mitre.org> Message-ID: : FYI, I found a forum where the PBLang developer acknowledges various : issues from the past, although the most recent problems aren't listed : there: : : http://pblforum.drmartinus.de/board.php?cat=2&fid=2&s=s Interesting, it had at least 4 issues that we didn't have, and I don't recall seeing on bugtraq/F-D. From coley at mitre.org Fri Sep 23 18:51:47 2005 From: coley at mitre.org (Steven M. Christey) Date: Fri Sep 23 18:53:28 2005 Subject: [VIM] vendor ACK inquiry for my little forum Message-ID: <200509232251.j8NMplXf006506@linus.mitre.org> FYI, I just posted an inquiry to a "my little forum" forum page asking for acknowledgement of the vulns discovered by rgod: http://marc.theaimsgroup.com/?l=bugtraq&m=112741430006983&w=2 The inquiry is at: http://www.mylittlehomepage.net/forum/forum_entry.php?id=1564 I just posted it, so no answer yet. - Steve From coley at mitre.org Tue Sep 27 14:47:11 2005 From: coley at mitre.org (Steven M. Christey) Date: Tue Sep 27 14:49:07 2005 Subject: [VIM] Vendor ACK for simplog SQL issues Message-ID: <200509271847.j8RIlBeh013316@linus.mitre.org> The bug report in the CONFIRM reference below has been marked with a "Verified" status and a "Fixed" resolution. It's being tagged as SQL injection by some VDB's but only some of the demo URLs suggest it. - Steve ====================================================== Candidate: CAN-2005-3076 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3076 Reference: CONFIRM:http://www.simplog.org/bugs/bug.php?op=show&bugid=55 Reference: BID:14897 Reference: URL:http://www.securityfocus.com/bid/14897 Reference: SECUNIA:16881 Reference: URL:http://secunia.com/advisories/16881 Simplog 0.9.1 might allow remote attackers to execute arbitrary SQL commands or trigger SQL error messages via invalid (1) pid, (2) blogid, (3) cid, or (4) m parameters to archive.php, or the (5) blogid parameter to blogadmin.php. From coley at mitre.org Wed Sep 28 13:30:37 2005 From: coley at mitre.org (Steven M. Christey) Date: Wed Sep 28 13:32:40 2005 Subject: [VIM] Is the Firefox PAC eval issue really a vulnerability? Message-ID: <200509281730.j8SHUbGl016064@linus.mitre.org> I noticed that most VDB's have decided to create an entry for the Firefox PAC eval crash: https://bugzilla.mozilla.org/show_bug.cgi?id=302100 While this issue was prominently listed under the "security and stability" section of the release notes for 1.0.7, I wonder if it qualifies as a security issue. Based on my very minimal understanding of browsers, it seems that most PAC scripts would come from a trusted source, e.g. an organization's IT department, and this trust is essential for proper operation of the browser (how else would a client know which proxies to use?) In addition, it seems that the PAC format is in Javascript, thus the provider of the PAC can already do various DoS attacks and probably other things since I'd imagine the PAC is processed with some sort of privileges. So it seems like the eval DoS isn't giving the PAC provider anything that they don't already have, and security boundaries aren't crossed, and it's not a security issue. Thoughts or corrections? By necessity I've created CAN-2005-3089 but included a disclaimer that this might not be a security issue. - Steve From sullo at cirt.net Wed Sep 28 17:50:20 2005 From: sullo at cirt.net (Sullo) Date: Wed Sep 28 17:52:26 2005 Subject: [VIM] Is the Firefox PAC eval issue really a vulnerability? In-Reply-To: <200509281730.j8SHUbGl016064@linus.mitre.org> References: <200509281730.j8SHUbGl016064@linus.mitre.org> Message-ID: <433B101C.40907@cirt.net> I'll preface with the fact that I know very little about proxies. Steven M. Christey wrote: > https://bugzilla.mozilla.org/show_bug.cgi?id=302100 > > > >Based on my very minimal understanding of browsers, it seems that most >PAC scripts would come from a trusted source, e.g. an organization's >IT department, and this trust is essential for proper operation of the >browser (how else would a client know which proxies to use?) > I'd argue that since it relies on external data (the .pac file contents--coming from a remote source), then it should be able to safely handle *anything* a .pac file could throw at it. >In >addition, it seems that the PAC format is in Javascript, thus the >provider of the PAC can already do various DoS attacks and probably >other things since I'd imagine the PAC is processed with some sort of >privileges. So it seems like the eval DoS isn't giving the PAC >provider anything that they don't already have, and security >boundaries aren't crossed, and it's not a security issue. > > While they may govern what I can and can't surf from work, my proxy admins have absolutely no access to my system. I just did some quick reading and couldn't confirm my idea that a .pac file could be auto-downloaded by a browser. However, if that's the case, any proxy in an anonymous proxy list could potentially exploit this. Did I just make that up? Either way, IMHO the pac parsing routines should happily ignore anything that is not exactly what they are looking for, whether it was accidental or someone replaced proxy.pac with a copy of Doom. -Sullo -- http://www.cirt.net/ | http://www.osvdb.org/ From jericho at attrition.org Fri Sep 30 05:54:17 2005 From: jericho at attrition.org (security curmudgeon) Date: Fri Sep 30 05:54:38 2005 Subject: [VIM] Re: PHP-Fusion v6.00.109 SQL Injection / admin|users credentials disclosure In-Reply-To: <433BA59D.1010400@gnucitizen.org> References: <20050928185508.28309.qmail@securityfocus.com> <433BA59D.1010400@gnucitizen.org> Message-ID: : I believe that this thing has been discovered and fixed long time ago. : check this out, maybe I am wrong: : http://www.gnucitizen.org/writings/php-fusion-messages.php-sql-injection-vulnerability.xhtml Your advisory: POST fields pm_email_notify and pm_save_sent are not properly sanitized. Rgod's advisory: msg_send=' UNION SELECT [..] BID 14489 / OSVDB 18708: msg_view=' So three advisories or points of disclosure, 4 different variables, all in messages.php it seems. Close, but this seems like a different issue.