From coley at mitre.org Tue Nov 1 14:09:20 2005 From: coley at mitre.org (Steven M. Christey) Date: Tue Nov 1 14:10:12 2005 Subject: [VIM] Vendor ACK for Snitz Forums post.asp XSS Message-ID: <200511011909.jA1J9K8g016490@linus.mitre.org> See CONFIRM reference below. - Steve ====================================================== Name: CVE-2005-3411 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3411 Reference: CONFIRM:http://forum.snitz.com/forum/topic.asp?TOPIC_ID=60011 Reference: BID:15241 Reference: URL:http://www.securityfocus.com/bid/15241 Reference: FRSIRT:ADV-2005-2261 Reference: URL:http://www.frsirt.com/english/advisories/2005/2261 Reference: SECUNIA:17385 Reference: URL:http://secunia.com/advisories/17385 Cross-site scripting (XSS) vulnerability in post.asp in Snitz Forums 2000 3.4.05 allows remote attackers to inject arbitrary web script or HTML via the type parameter in a Topic method. From coley at linus.mitre.org Wed Nov 2 16:11:04 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed Nov 2 16:11:57 2005 Subject: [VIM] vendor dispute of CVE-2005-3066 (fwd) Message-ID: FYI. Note that the nature of their dispute is based on stored XSS (e.g. injection of HTML into static pages or databases). Their dispute does not mention reflected XSS (i.e. having a user click on a link which then causes the XSS to be reflected back to the user), so to my way of thinking, this might be an erroneous dispute. I have asked them for clarification. - Steve ---------- Forwarded message ---------- Date: Wed, 2 Nov 2005 14:43:51 -0600 From: ScriptSolutions To: cve@mitre.org Subject: CVE-2005-3066 Dear Sir/Madam, I am the programmer of PerlDiver, the program which is referenced as a "candidate" on your site (http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3066). Please note that PerlDiver has never stored user input from the browser, much less returned that stored data to other users -- actions crucial to the exploitation of XSS vulnerabilities. As such, PerlDiver is incapable of being exploited in this manner. We consider exploitlabs to be irresponsible and malicious in their reporting of a completely harmless omission. We respectfully request that you remove the advisory from your sites as well as reconsider the importance of any future exploitlabs submission before permitting their trivial findings to slander reputable companies. You may see the details of our response to exploitlabs at http://www.scriptsolutions.com/support/showflat.pl?Board=PDBugs&Number =443 Thank you for your consideration. Best regards, Jasmine Merced From coley at mitre.org Wed Nov 2 19:50:53 2005 From: coley at mitre.org (Steven M. Christey) Date: Wed Nov 2 19:51:42 2005 Subject: [VIM] Mandrake/Mandriva mass URL changes Message-ID: <200511030050.jA30orMo018975@linus.mitre.org> URLs to Mandriva/Mandrake advisories have been yanked out from underneath VDB's. New URL is: http://frontal2.mandriva.com/security/advisories?name=[mandrakeID] - Steve From smoore at securityglobal.net Wed Nov 2 20:12:17 2005 From: smoore at securityglobal.net (Stuart Moore) Date: Wed Nov 2 20:13:35 2005 Subject: [VIM] vendor dispute of CVE-2005-3066 (fwd) In-Reply-To: References: Message-ID: <436963F1.1090004@securityglobal.net> Steve, This vendor does not understand XSS, stating that it is only a problem when a product *stores* information :-( I confirmed the bug in 2.01. Perhaps some education is in order ... Stuart -- Stuart Moore SecurityTracker.com SecurityGlobal.net LLC smoore@securityglobal.net Steven M. Christey wrote: > FYI. > > Note that the nature of their dispute is based on stored XSS (e.g. > injection of HTML into static pages or databases). Their dispute does not > mention reflected XSS (i.e. having a user click on a link which then > causes the XSS to be reflected back to the user), so to my way of > thinking, this might be an erroneous dispute. I have asked them for > clarification. > > - Steve > > > ---------- Forwarded message ---------- > Date: Wed, 2 Nov 2005 14:43:51 -0600 > From: ScriptSolutions > To: cve@mitre.org > Subject: CVE-2005-3066 > > Dear Sir/Madam, > > I am the programmer of PerlDiver, the program which is referenced as a > "candidate" on your site > (http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3066). > Please note that PerlDiver has never stored user input from the > browser, much less returned that stored data to other users -- actions > crucial to the exploitation of XSS vulnerabilities. As such, > PerlDiver is incapable of being exploited in this manner. > > We consider exploitlabs to be irresponsible and malicious in their > reporting of a completely harmless omission. We respectfully request > that you remove the advisory from your sites as well as reconsider the > importance of any future exploitlabs submission before permitting > their trivial findings to slander reputable companies. > > You may see the details of our response to exploitlabs at > http://www.scriptsolutions.com/support/showflat.pl?Board=PDBugs&Number > =443 > > Thank you for your consideration. > > Best regards, > Jasmine Merced > > > From coley at linus.mitre.org Wed Nov 2 20:17:35 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed Nov 2 20:18:25 2005 Subject: [VIM] vendor dispute of CVE-2005-3066 (fwd) In-Reply-To: <436963F1.1090004@securityglobal.net> References: <436963F1.1090004@securityglobal.net> Message-ID: On Wed, 2 Nov 2005, Stuart Moore wrote: > This vendor does not understand XSS, stating that it is only a problem > when a product *stores* information :-( > > I confirmed the bug in 2.01. > > Perhaps some education is in order ... I mentioned reflected XSS and pointed them to the OWASP Top Ten description of it. We'll see what happens next. I neglected to tell them how Donnie Werner is frequently right, but I'm not sure it would have been helpful. - Steve From jericho at attrition.org Fri Nov 4 07:14:24 2005 From: jericho at attrition.org (security curmudgeon) Date: Fri Nov 4 07:14:35 2005 Subject: [VIM] Mandrake/Mandriva mass URL changes In-Reply-To: <200511030050.jA30orMo018975@linus.mitre.org> References: <200511030050.jA30orMo018975@linus.mitre.org> Message-ID: : URLs to Mandriva/Mandrake advisories have been yanked out from : underneath VDB's. : : New URL is: : : http://frontal2.mandriva.com/security/advisories?name=[mandrakeID] http://www.osvdb.org/blog/?p=59 Advisory Archives 102 (why Mandriva hates VDBs) [..] =) From James.Williams at ca.com Wed Nov 9 01:00:14 2005 From: James.Williams at ca.com (Williams, James K) Date: Wed Nov 9 01:01:50 2005 Subject: [VIM] Is it a virus variant or an AV product vuln? Message-ID: This issue refuses to die. What is your opinion - virus variant or vuln? And why? The two links below are for the two main threads on FD. Multiple Vendor Anti-Virus Software Detection Evasion Vulnerability through forged magic byte http://marc.theaimsgroup.com/?l=full-disclosure&m=113020970919228&w=2 http://marc.theaimsgroup.com/?l=full-disclosure&m=113040021629991&w=2 Regards, ken From coley at linus.mitre.org Wed Nov 9 03:58:43 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed Nov 9 04:00:03 2005 Subject: [VIM] Is it a virus variant or an AV product vuln? In-Reply-To: References: Message-ID: I treated these as vulns in CVE because they deal with specific manipulations of inputs that would seem to make for an invalid executable, but do not when they are dealt with on the end system. Intermediaries like proxies, firewalls, etc. have special requirements: they have to be aware of how the end systems handle the data that flows through the intermediaries. Because of their roles as protectors, they should be held to a higher standard than "normal" products. I recently did a Bugtraq post on "interpretation conflicts," which the magic byte issue falls under. In CVE, I've included other AV-bypassing techniques e.g. malformed ZIP files that can still be processed by some programs. Maybe intermediaries shouldn't be "blamed" for non-standard behaviors on end systems, but the interaction is of significant note because it bypasses a protection mechanism. Probably a slippery-slope area but there it is. - Steve On Wed, 9 Nov 2005, Williams, James K wrote: > > This issue refuses to die. What is your opinion - virus variant or > vuln? And why? > > The two links below are for the two main threads on FD. > > Multiple Vendor Anti-Virus Software Detection Evasion Vulnerability > through forged magic byte > http://marc.theaimsgroup.com/?l=full-disclosure&m=113020970919228&w=2 > http://marc.theaimsgroup.com/?l=full-disclosure&m=113040021629991&w=2 > > Regards, > ken > From jericho at attrition.org Sun Nov 13 07:16:16 2005 From: jericho at attrition.org (security curmudgeon) Date: Sun Nov 13 07:16:27 2005 Subject: [VIM] site redirects: vulnerability or no? Message-ID: Sullo and I have been debating this casually, and the only thing that hasn't forced our decision is the reports aren't too frequent (yet?). A site or product offers a script to redirect you to another site. They are typically found as part of leaving a site in some fashion. Example: http://[target]/goodbye.php?http://arbitrary.moo/ If you obscure the 'arbitrary.moo' by using encoding, IP address, TinyURL or a number of other methods, you have what looks like a legitimate link to a site that many people may click on w/o realizing it. This is very handy and likely widely abused in phishing attacks, which is the reason some people are disclosing them. But, is it a *vulnerability*? If it is, do you see your database assigning a unique ID to each product that does this (easily hundreds)? Or a sort of generic entry covering the concept? Or none at all? From jericho at attrition.org Sun Nov 13 08:25:31 2005 From: jericho at attrition.org (security curmudgeon) Date: Sun Nov 13 08:25:34 2005 Subject: [VIM] welcome Weld Pond Message-ID: doubt he needs introduction to this small crowd =) From sullo at cirt.net Sun Nov 13 17:41:29 2005 From: sullo at cirt.net (Sullo) Date: Sun Nov 13 17:43:09 2005 Subject: [VIM] site redirects: vulnerability or no? In-Reply-To: References: Message-ID: <4377C119.5000501@cirt.net> security curmudgeon wrote: > http://[target]/goodbye.php?http://arbitrary.moo/ > > If you obscure the 'arbitrary.moo' by using encoding, IP address, > TinyURL or a number of other methods, you have what looks like a > legitimate link to a site that many people may click on w/o realizing > it. This is very handy and likely widely abused in phishing attacks, > which is the reason some people are disclosing them. > I don't think obfuscation is *required*, as most victims of phishing probably wouldn't notice anyway. Any URL long enough to push past the edge of the location field wouldn't raise an eyebrow. > But, is it a *vulnerability*? > I believe so. I think the proper way to do this is to have a white-list of allowed redirects (or properly built regex's that don't over-match), and/or an intermediary page that tells the user they are going to a 3rd party site. I am interested to hear how others feel about these & how some of the other DBs are handling (or not). -Sullo -- http://www.cirt.net/ | http://www.osvdb.org/ From smoore at securityglobal.net Mon Nov 14 02:42:01 2005 From: smoore at securityglobal.net (Stuart Moore) Date: Mon Nov 14 02:43:46 2005 Subject: [VIM] site redirects: vulnerability or no? In-Reply-To: <4377C119.5000501@cirt.net> References: <4377C119.5000501@cirt.net> Message-ID: <43783FC9.6050309@securityglobal.net> Sometimes when faced with a toss-up decision, we will look at the advertised purpose of the product or will consider what expectations a reasonable administrator would have regarding the functionality. Stuart Sullo wrote: > security curmudgeon wrote: > > >>http://[target]/goodbye.php?http://arbitrary.moo/ >> >>If you obscure the 'arbitrary.moo' by using encoding, IP address, >>TinyURL or a number of other methods, you have what looks like a >>legitimate link to a site that many people may click on w/o realizing >>it. This is very handy and likely widely abused in phishing attacks, >>which is the reason some people are disclosing them. >> > > I don't think obfuscation is *required*, as most victims of phishing > probably wouldn't notice anyway. Any URL long enough to push past the > edge of the location field wouldn't raise an eyebrow. > > >>But, is it a *vulnerability*? >> > > I believe so. I think the proper way to do this is to have a white-list > of allowed redirects (or properly built regex's that don't over-match), > and/or an intermediary page that tells the user they are going to a 3rd > party site. > > I am interested to hear how others feel about these & how some of the > other DBs are handling (or not). > > -Sullo > > From weld at vulnwatch.org Mon Nov 14 12:18:31 2005 From: weld at vulnwatch.org (Chris Wysopal) Date: Mon Nov 14 11:44:53 2005 Subject: [VIM] site redirects: vulnerability or no? In-Reply-To: <4377C119.5000501@cirt.net> References: <4377C119.5000501@cirt.net> Message-ID: On Sun, 13 Nov 2005, Sullo wrote: > security curmudgeon wrote: > > > http://[target]/goodbye.php?http://arbitrary.moo/ > > > > If you obscure the 'arbitrary.moo' by using encoding, IP address, > > TinyURL or a number of other methods, you have what looks like a > > legitimate link to a site that many people may click on w/o realizing > > it. This is very handy and likely widely abused in phishing attacks, > > which is the reason some people are disclosing them. > > > I don't think obfuscation is *required*, as most victims of phishing > probably wouldn't notice anyway. Any URL long enough to push past the > edge of the location field wouldn't raise an eyebrow. > > > But, is it a *vulnerability*? > > > I believe so. I think the proper way to do this is to have a white-list > of allowed redirects (or properly built regex's that don't over-match), > and/or an intermediary page that tells the user they are going to a 3rd > party site. > > I am interested to hear how others feel about these & how some of the > other DBs are handling (or not). Hi all. First Post. I agree that this is a vulnerability. Are you talking about putting vulnerabile websites into the VDB or just software that implements this redirect? This is going to get more interesting over time as software with APIs, etc. moves to become a service such as maps.google.com. I can't imagine putting every website that has this problem in the VDB. -Chris From jericho at attrition.org Mon Nov 14 18:27:57 2005 From: jericho at attrition.org (security curmudgeon) Date: Mon Nov 14 18:27:59 2005 Subject: [VIM] site redirects: vulnerability or no? In-Reply-To: References: <4377C119.5000501@cirt.net> Message-ID: : Hi all. First Post. : : I agree that this is a vulnerability. Are you talking about putting : vulnerabile websites into the VDB or just software that implements this : redirect? This is going to get more interesting over time as software : with APIs, etc. moves to become a service such as maps.google.com. I : can't imagine putting every website that has this problem in the VDB. If it is deemed a vulnerability, then an entry would be added based on software packages, not web sites. I don't believe any of the databases track vulns in web sites really. If a vuln, then the second question becomes.. one entry for the concept, or one entry per package. And last, why is this a vulnerability in your eyes? One could argue that the script is doing exactly what was intended, and the only vulnerability is the person who blindly follows a link w/o realizing what they are doing. This could also technically make 'TinyURL' a vulnerability since it has the same outcome and even better concealment of the target URL. From weld at vulnwatch.org Mon Nov 14 19:42:08 2005 From: weld at vulnwatch.org (Chris Wysopal) Date: Mon Nov 14 18:57:55 2005 Subject: [VIM] site redirects: vulnerability or no? In-Reply-To: References: <4377C119.5000501@cirt.net> Message-ID: On Mon, 14 Nov 2005, security curmudgeon wrote: > If a vuln, then the second question becomes.. one entry for the concept, > or one entry per package. > > And last, why is this a vulnerability in your eyes? One could argue that > the script is doing exactly what was intended, and the only vulnerability > is the person who blindly follows a link w/o realizing what they are > doing. This could also technically make 'TinyURL' a vulnerability since it > has the same outcome and even better concealment of the target URL. To pull off a convincing phishing attack you need to put a few pieces together. Having an URL that looks legit is just one part. TinyURLs don't look legit. But think about something that said click here for the latest microsoft download and the url was http://www.microsoft.com/something?www.sitename.com/foobar.exe I bet Microsoft would want to fix that if notified. Just because it is a vulnerability doesn't mean it makes sense to track it in the VDB. At some point a vulnerability gets so minor no one really cares, such as many information disclosure issues. I think this one falls below the level of tracking. -Chris From sullo at cirt.net Mon Nov 14 19:47:10 2005 From: sullo at cirt.net (Sullo) Date: Mon Nov 14 19:48:56 2005 Subject: [VIM] site redirects: vulnerability or no? In-Reply-To: References: <4377C119.5000501@cirt.net> Message-ID: <4379300E.4010605@cirt.net> Chris Wysopal wrote: >On Mon, 14 Nov 2005, security curmudgeon wrote: > > > >>If a vuln, then the second question becomes.. one entry for the concept, >>or one entry per package. >> >>And last, why is this a vulnerability in your eyes? One could argue that >>the script is doing exactly what was intended, and the only vulnerability >>is the person who blindly follows a link w/o realizing what they are >>doing. This could also technically make 'TinyURL' a vulnerability since it >>has the same outcome and even better concealment of the target URL. >> >> > >To pull off a convincing phishing attack you need to put a few pieces >together. Having an URL that looks legit is just one part. TinyURLs >don't look legit. But think about something that said click here for the >latest microsoft download and the url was >http://www.microsoft.com/something?www.sitename.com/foobar.exe >I bet Microsoft would want to fix that if notified. > >Just because it is a vulnerability doesn't mean it makes sense to track it >in the VDB. At some point a vulnerability gets so minor no one really >cares, such as many information disclosure issues. I think this one falls >below the level of tracking. > > I think it bears at least one entry. Having been on the end of trying to convince developers to not allow arbitrary redirects because it *was* being used for phishing, having VDB entries that explained the issue, linked to other resources (news articles, "fixes", discussions, etc.) would have been really helpful. Since it was in-house code, there was no vendor bulletin for me to point at. But just today I was doing some code auditing (which is what they get for leaving a .php.bak file behind) and found that they tried to validate URLs, but incorrectly. So I could sneak a url like www.cnn.com.cirt.net (assuming www.cnn.com was allowed) and pass their "site validation" code... in this case I would call it an individual vuln because they have protection that failed. I think that's my $.04 on the subject. -Sullo -- http://www.cirt.net/ | http://www.osvdb.org/ From coley at linus.mitre.org Wed Nov 16 04:45:47 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed Nov 16 04:47:30 2005 Subject: [VIM] site redirects: vulnerability or no? In-Reply-To: References: <4377C119.5000501@cirt.net> Message-ID: I'm on vacation so will be brief and comment on threads that I haven't even read just so this will be here when I get back :) Phishing... generally for CVE the litmus test is if a "reasonably cautious" user could be fooled, but if it's only successful for grandmas and highly un-knowledgeable people then I'll leave it up to the AV/malware people. Status bar and SSL icon hacks fall under "fools reasonably cautious users" for example. - Steve From jericho at attrition.org Wed Nov 16 06:20:37 2005 From: jericho at attrition.org (security curmudgeon) Date: Wed Nov 16 06:20:38 2005 Subject: [VIM] Flash.ocx function name? (fwd) Message-ID: ---------- Forwarded message ---------- From: security curmudgeon To: Steve Manzuik Date: Wed, 16 Nov 2005 06:18:39 -0500 (EST) Subject: Flash.ocx function name? 18825: Macromedia Flash Player Flash.ocx Unspecified Function Arbitrary Code Execution I had to change this to 'unspecified function' because of the release of another vuln shortly after eEye's. 1002580: Macromedia Flash Player Flash.ocx ActionDefineFunction Function Arbitrary Code Execution I'm about to move this to stable but this comes from: http://archives.neohapsis.com/archives/fulldisclosure/2005-11/0154.html This issue is similar to CAN-2005-2628 (as reported by eEye Digital Security on November 4, 2005) but affects a different function. Coincidentally, Macromedia has received our notification of this bug on the same day (June 27). So to help distinguish, can eEye release the vulnerable function name they discovered? Thanks! Brian From jericho at attrition.org Wed Nov 16 06:26:58 2005 From: jericho at attrition.org (security curmudgeon) Date: Wed Nov 16 06:27:02 2005 Subject: [VIM] odd Macromedia wording Message-ID: I'm sure this wasn't intentional, but the wording stuck out to me. http://www.macromedia.com/devnet/security/security_zone/mpsb05-10.html Summary The Breeze Communication Server and Breeze Live Server do not sufficiently validate some RTMP data. This can cause server instability or crashes for licensed customers. How about .. unlicensed customers? If you warez a copy, are you safe from this attack? Does this imply that licensed customers are sending RTMP data back/forth to Macromedia, and the DoS lies in that? From coley at linus.mitre.org Wed Nov 16 07:43:41 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed Nov 16 07:45:25 2005 Subject: [VIM] odd Macromedia wording In-Reply-To: References: Message-ID: On Wed, 16 Nov 2005, security curmudgeon wrote: > The Breeze Communication Server and Breeze Live Server do not > sufficiently validate some RTMP data. This can cause server instability > or crashes for licensed customers. I thought you were gonna complain about the "validate" phrase. That could mean anything. "Validation" as a concept has, at best, many different definitions. Does it not handle syntactically invalid inputs? In what specific way is it syntactically invalid, e.g. missing an argument, having extra separator characters, open/closing sequences in the wrong order, etc.? Or do they mean "semantically" invalid (whatever THAT means). The lack of these kinds of details makes it more difficult to understand the specific programming error and/or associated attacker manipulations. Some vendors might not want to provide such details because of the belief that it makes it easier to construct functioning exploits, but I've seen the "invalid" term used by vendors who don't normally hide such details. Then again, I could imagine that most sysadmins wouldn't care about such specifics. - Steve From akoren at gmail.com Wed Nov 16 06:57:11 2005 From: akoren at gmail.com (Alexander Koren) Date: Wed Nov 16 07:53:50 2005 Subject: [VIM] odd Macromedia wording In-Reply-To: References: Message-ID: <992692C8-28EE-4B3E-9717-8AC6554352C7@gmail.com> > How about .. unlicensed customers? If you warez a copy, are you > safe from this attack? Does this imply that licensed customers are > sending RTMP data back/forth to Macromedia, and the DoS lies in that? they have two different types: a software license which let you host and manage your own Breeze server and a subscription model if you want a Breeze server hosted by Macromedia. Anyway, you will need a license to be able to connect. www.osvdb.org -- everything is vulnerable. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2361 bytes Desc: not available Url : http://www.attrition.org/pipermail/vim/attachments/20051116/ed2e00f0/smime.bin From jericho at attrition.org Fri Nov 18 06:32:18 2005 From: jericho at attrition.org (security curmudgeon) Date: Fri Nov 18 06:32:21 2005 Subject: [VIM] gnump3d stuff Message-ID: First, traversal (CVE 2005-3123) may have extra concerns. While flagged BUGFIX and not SECURITY, "allow files to start with ..." stands out to me. 2.9.7 [ 28th October 2005 ] - BUGFIX: The previous release was broken. - BUGFIX: Allow files to start with ... 2.9.6 [ 28th October 2005 ] - SECURITY: Prevent path traversal. [CVE-2005-3123] Second, two more issues that have CVE entries (but aren't open), and I don't recall seeing before this: 2.9.8 [ 17th November 2005 ] - SECURITY: Remove insecure usage of /tmp. [CVE-2005-3349] - SECURITY: Filter input parameters/cookies. [CVE-2005-3355] From coley at mitre.org Fri Nov 18 15:40:17 2005 From: coley at mitre.org (Steven M. Christey) Date: Fri Nov 18 15:42:11 2005 Subject: [VIM] How CVE is handling the ISAKMP mess Message-ID: <200511182040.jAIKeHGI018956@linus.mitre.org> All, FYI. For the ISAKMP PROTOS mess, I've decided to create 3 generic CANs - one for "denial of service," one for format strings, and one for buffer overflows - then create specific CANs for specific implementations when available. One problem with this is that most vendors probably won't provide enough details to know which type of issue they're vulnerable to. Cisco just said "denial of service" but one wonders if they're vulnerable to buffer overflows and are assuming that their newfangled overflow protection is just a DoS, but I digress. PROTOS totally rocks, but these kinds of disclosures are regular headaches for CVE, because we *should* be producing dozens or hundreds of CANs, but usually only wind up creating a handful due to lack of relevant details. - Steve ====================================================== Name: CVE-2005-3666 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3666 Reference: MISC:http://www.niscc.gov.uk/niscc/docs/br-20051114-01013.html?lang=en Reference: MISC:http://jvn.jp/niscc/NISCC-273756/index.html Reference: CERT-VN:VU#226364 Reference: URL:http://www.kb.cert.org/vuls/id/226364 Multiple unspecified format string vulnerabilities in multiple unspecified implementations of Internet Key Exchange version 1 (IKEv1) have multiple unspecified attack vectors and impacts, as demonstrated by the PROTOS ISAKMP Test Suite for IKEv1. NOTE: due to the lack of information in the original sources, it is likely that this candidate will be REJECTed once it is known which implementations are actually vulnerable. ====================================================== Name: CVE-2005-3667 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3667 Reference: MISC:http://www.niscc.gov.uk/niscc/docs/br-20051114-01013.html?lang=en Reference: MISC:http://jvn.jp/niscc/NISCC-273756/index.html Reference: CERT-VN:VU#226364 Reference: URL:http://www.kb.cert.org/vuls/id/226364 Multiple unspecified vulnerabilities in multiple unspecified implementations of Internet Key Exchange version 1 (IKEv1) have multiple unspecified attack vectors and impacts related to denial of service, as demonstrated by the PROTOS ISAKMP Test Suite for IKEv1. NOTE: due to the lack of information in the original sources, it is likely that this candidate will be REJECTed once it is known which implementations are actually vulnerable. In addition, since "denial of service" is an impact and not a vulnerability, it is unknown which underlying vulnerabilities are actually covered by this particular candidate. ====================================================== Name: CVE-2005-3668 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3668 Reference: MISC:http://www.niscc.gov.uk/niscc/docs/br-20051114-01013.html?lang=en Reference: MISC:http://jvn.jp/niscc/NISCC-273756/index.html Reference: CERT-VN:VU#226364 Reference: URL:http://www.kb.cert.org/vuls/id/226364 Multiple buffer overflows in multiple unspecified implementations of Internet Key Exchange version 1 (IKEv1) have multiple unspecified attack vectors and impacts related to denial of service, as demonstrated by the PROTOS ISAKMP Test Suite for IKEv1. NOTE: due to the lack of information in the original sources, it is likely that this candidate will be REJECTed once it is known which implementations are actually vulnerable. ====================================================== Name: CVE-2005-3669 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3669 Reference: MISC:http://www.niscc.gov.uk/niscc/docs/br-20051114-01013.html?lang=en Reference: CISCO:20051117 Multiple Vulnerabilities Found by PROTOS IPSec Test Suite Reference: URL:http://www.cisco.com/warp/public/707/cisco-sa-20051114-ipsec.shtml Reference: MISC:http://jvn.jp/niscc/NISCC-273756/index.html Reference: CERT-VN:VU#226364 Reference: URL:http://www.kb.cert.org/vuls/id/226364 Multiple unspecified vulnerabilities in the Internet Key Exchange version 1 (IKEv1) implementation in multiple Cisco products allow remote attackers to cause a denial of service (device reset) via certain malformed IKE packets, as demonstrated by the PROTOS ISAKMP Test Suite for IKEv1. From jericho at attrition.org Fri Nov 18 15:48:25 2005 From: jericho at attrition.org (security curmudgeon) Date: Fri Nov 18 15:48:26 2005 Subject: [VIM] How CVE is handling the ISAKMP mess In-Reply-To: <200511182040.jAIKeHGI018956@linus.mitre.org> References: <200511182040.jAIKeHGI018956@linus.mitre.org> Message-ID: : FYI. For the ISAKMP PROTOS mess, I've decided to create 3 generic CANs : - one for "denial of service," one for format strings, and one for : buffer overflows - then create specific CANs for specific : implementations when available. One problem with this is that most : vendors probably won't provide enough details to know which type of : issue they're vulnerable to. Cisco just said "denial of service" but : one wonders if they're vulnerable to buffer overflows and are assuming : that their newfangled overflow protection is just a DoS, but I digress. OSVDB did close.. one generic entry for Denial of Service, one for 'Unspecified' which will cover BO/FS stuff, as we get details. From there we'll split it out by vendor or protocol issue. From coley at linus.mitre.org Fri Nov 18 15:52:53 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri Nov 18 15:54:47 2005 Subject: [VIM] How CVE is handling the ISAKMP mess In-Reply-To: References: <200511182040.jAIKeHGI018956@linus.mitre.org> Message-ID: The "status" fields in the CERT VU list a few vulnerable implementations with pointers to advisories. That's more information than in the original NISCC advisory. - Steve On Fri, 18 Nov 2005, security curmudgeon wrote: > > : FYI. For the ISAKMP PROTOS mess, I've decided to create 3 generic CANs > : - one for "denial of service," one for format strings, and one for > : buffer overflows - then create specific CANs for specific > : implementations when available. One problem with this is that most > : vendors probably won't provide enough details to know which type of > : issue they're vulnerable to. Cisco just said "denial of service" but > : one wonders if they're vulnerable to buffer overflows and are assuming > : that their newfangled overflow protection is just a DoS, but I digress. > > OSVDB did close.. one generic entry for Denial of Service, one for > 'Unspecified' which will cover BO/FS stuff, as we get details. From there > we'll split it out by vendor or protocol issue. > > From coley at linus.mitre.org Fri Nov 18 16:01:20 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri Nov 18 16:03:14 2005 Subject: [VIM] How CVE is handling the ISAKMP mess In-Reply-To: References: <200511182040.jAIKeHGI018956@linus.mitre.org> Message-ID: On Fri, 18 Nov 2005, security curmudgeon wrote: > OSVDB did close.. one generic entry for Denial of Service, one for > 'Unspecified' which will cover BO/FS stuff, as we get details. From there > we'll split it out by vendor or protocol issue. I hate splitting by "denial of service" since it's an impact (consequence) and not a vulnerability - i.e. it gives no indication whatsoever of the underlying fault/flaw and/or the associated attack manipulations. "Denial of service" is the result of the exploitation of some vulnerability - but when it's the only bit of information we have, we're forced to use it. One of my hopes is that "DoS" as a vulnerability concept will die a quiet death. Let's get to the REAL problems - how the input was malformed or otherwise manipulated, and what errors the application made when mis-handling the inputs. CVE has a "dos-malformed" flaw type which is always in the top 5, specifically because it's a super-class that has no other details. That's an indication of a large gap in vuln research these days. - Steve From coley at linus.mitre.org Fri Nov 18 16:10:08 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri Nov 18 16:12:03 2005 Subject: [VIM] gnump3d stuff In-Reply-To: References: Message-ID: On Fri, 18 Nov 2005, security curmudgeon wrote: > First, traversal (CVE 2005-3123) may have extra concerns. While flagged > BUGFIX and not SECURITY, "allow files to start with ..." stands out to > me. hmmmm, sounds unusual. > 2.9.7 [ 28th October 2005 ] > - BUGFIX: The previous release was broken. > - BUGFIX: Allow files to start with ... > 2.9.6 [ 28th October 2005 ] > - SECURITY: Prevent path traversal. [CVE-2005-3123] > > Second, two more issues that have CVE entries (but aren't open), and I > don't recall seeing before this: > > 2.9.8 [ 17th November 2005 ] > - SECURITY: Remove insecure usage of /tmp. [CVE-2005-3349] > - SECURITY: Filter input parameters/cookies. [CVE-2005-3355] These were assigned by a non-MITRE Candidate Naming Authority (CNA) so I wasn't aware of them either. Nice catch! - Steve From coley at mitre.org Tue Nov 22 19:41:53 2005 From: coley at mitre.org (Steven M. Christey) Date: Tue Nov 22 19:44:04 2005 Subject: [VIM] Vendor ACK of MyBB issue Message-ID: <200511230041.jAN0frOQ022105@linus.mitre.org> Vendor acknowledgement of CVE-2005-3326 (usercp.php?awayday SQL injection in MyBB) is at: http://community.mybboard.net/showthread.php?tid=4507&pid=27223#pid27223 along with a small reference to a DoS, which is alluded to in SECUNIA:17577. The forum post "MyBB PR2 Security Update [1/11/05]" identifies "The major security issue could allow your board to be compromised via an SQL injection based vulnerability... discovered on the 26th October..." and includes usercp.php in the patched files, which shows cleansing of the awayday parameter. The date also aligns with the Bugtraq post. - Steve From coley at mitre.org Wed Nov 23 19:27:29 2005 From: coley at mitre.org (Steven M. Christey) Date: Wed Nov 23 19:29:53 2005 Subject: [VIM] New PhpMyAdmin vuln Message-ID: <200511240027.jAO0RT3e001446@linus.mitre.org> Disclosed by the vendor on their security web page... http://www.phpmyadmin.net/home_page/security.php?issue=PMASA-2005-7 - Steve From coley at mitre.org Fri Nov 25 16:46:32 2005 From: coley at mitre.org (Steven M. Christey) Date: Fri Nov 25 16:49:02 2005 Subject: [VIM] Minor nit - Unclassified NewsBoard SQL injection Message-ID: <200511252146.jAPLkWUl019997@linus.mitre.org> VDBs are describing the Unclassified NewsBoard SQL injection issue from a few days ago by saying that the DateFrom parameter is affected. They seem to have missed DateUntil: 1) In the title of rgod's advisory :) it says: Unclassified NewsBoard 1.5.3 patch level 3 "DateFrom" & "DateUntil" blind SQL injection 2) Then: vulnerable code near lines 393-454 in search.inc.php: "DateFrom" and "DateUntil" arguments are not properly sanitized before to be passed to a query 3) Then: http://[target]/[path]/forum.php?req=search&Query=suntzu&ResultView=2&Sort=2&DateFrom=[SQL]&DateUntil=[SQL]&Forum=0 The bulk of the advisory concentrates on "DateFrom", so that must be what happened. Not that people would just derive their descriptions from someone else's analysis... oh no, that NEVER happens ;-) - Steve ====================================================== Name: CVE-2005-3686 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3686 Reference: MISC:http://rgod.altervista.org/unb153pl3_xpl.html Reference: MISC:http://packetstormsecurity.org/0511-exploits/unb153pl3_xpl.html Reference: BID:15466 Reference: URL:http://www.securityfocus.com/bid/15466 Reference: FRSIRT:ADV-2005-2487 Reference: URL:http://www.frsirt.com/english/advisories/2005/2487 Reference: OSVDB:20951 Reference: URL:http://www.osvdb.org/20951 Reference: SECUNIA:17614 Reference: URL:http://secunia.com/advisories/17614 SQL injection vulnerability in search.inc.php in Unclassified NewsBoard before 1.5.3 Patch 4 allows remote attackers to execute arbitrary SQL commands via the (1) DateFrom or (2) DateUntil parameter to forum.php. From coley at mitre.org Sun Nov 27 03:05:58 2005 From: coley at mitre.org (Steven M. Christey) Date: Sun Nov 27 03:08:36 2005 Subject: [VIM] Confirmation (source inspection) of various r0t-discovered issues Message-ID: <200511270805.jAR85w5q018504@cairo.mitre.org> I've taken a small interest in observing r0t (r0t3d3Vil) since he's done a whole lot of reports in the past couple of days in software that hasn't been reported vulnerable before... plus his blog profile says he's 14. Most of his analyses are of for-purchase products, so I couldn't check those. At least one demo site for one vendor had been tested by him, as his leftover XSS attempts indicated :-/ so some of his results might be coming from tests of vendor demo sites. Anyway, for some products with source available, I was able to confirm - by source inspection only - several recent issues. CVE-2005-3834 searchFor is directly inserted into a $title variable. CVE-2005-3846 line 205 news.php - $where="AND c.category_id=".$_REQUEST['category'].""; CVE-2005-3853 Multiple locations exist, including the title() function where a $_GET['id'] (line 174) is fed directly into a $query variable without quoting (line 179), which is then fed to mysql_query() (line 180). source code review of 1.3 shows that snews.php is the affected file. For CVE-2005-3833 - Tunez "songinfo.php?song_id=[SQL]" SQL injection - source code inspection of songinfo.php suggests that an addslashes() is performed on the song_id parameter, so this report might be incorrect or associated with a different type of issue, e.g. a SQL error from a query with a non-numeric value. - Steve ====================================================== Name: CVE-2005-3834 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3834 Reference: MISC:http://pridels.blogspot.com/2005/11/tunez-sql-and-xss-vuln.html Reference: BID:15548 Reference: URL:http://www.securityfocus.com/bid/15548 Reference: OSVDB:21063 Reference: URL:http://www.osvdb.org/21063 Reference: SECUNIA:17692 Reference: URL:http://secunia.com/advisories/17692 Cross-site scripting (XSS) vulnerability in search.php in Tunez 1.21 and earlier allows remote attackers to inject arbitrary web script or HTML via the searchFor parameter. ====================================================== Name: CVE-2005-3846 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3846 Reference: MISC:http://pridels.blogspot.com/2005/11/fantastic-news-category-sql-inj.html Reference: FRSIRT:ADV-2005-2595 Reference: URL:http://www.frsirt.com/english/advisories/2005/2595 SQL injection vulnerability in news.php in Fantastic News 2.1.1 and earlier allows remote attackers to execute arbitrary SQL commands via the category parameter. ====================================================== Name: CVE-2005-3853 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3853 Reference: MISC:http://pridels.blogspot.com/2005/11/snews-13-sql-injection.html Reference: OSVDB:21093 Reference: URL:http://www.osvdb.org/21093 Reference: SECUNIA:17688 Reference: URL:http://secunia.com/advisories/17688 SQL injection vulnerability in snews.php in sNews 1.3 and earlier allows remote attackers to execute arbitrary SQL commands via the (1) id and (2) category parameters to index.php. From jericho at attrition.org Sun Nov 27 03:24:41 2005 From: jericho at attrition.org (security curmudgeon) Date: Sun Nov 27 03:24:44 2005 Subject: [VIM] Confirmation (source inspection) of various r0t-discovered issues In-Reply-To: <200511270805.jAR85w5q018504@cairo.mitre.org> References: <200511270805.jAR85w5q018504@cairo.mitre.org> Message-ID: : I've taken a small interest in observing r0t (r0t3d3Vil) since he's done : a whole lot of reports in the past couple of days in software that : hasn't been reported vulnerable before... plus his blog profile says : he's 14. Yep, we've been curious about this. 99% of his finds are simple cut/paste XSS or single back tick SQL injection testing, so it isn't surprising on one hand. The volume of products is interesting though. It made me wonder if someone had finally scripted something out to wget, untar, configure, make, make install and auto-paros (or the equiv) the software. : Most of his analyses are of for-purchase products, so I couldn't check : those. At least one demo site for one vendor had been tested by him, as : his leftover XSS attempts indicated :-/ so some of his results might be : coming from tests of vendor demo sites. : : Anyway, for some products with source available, I was able to confirm - : by source inspection only - several recent issues. One of the finds had what I took to be vendor confirmation. There was a freshmeat announce for a new version of software that fixed XSS and SQL Injections. It was released a day after r0t's mail to us and secunia (not sure who else he is mailing), was the next logical version, etc. : For CVE-2005-3833 - Tunez "songinfo.php?song_id=[SQL]" SQL injection - : source code inspection of songinfo.php suggests that an addslashes() is : performed on the song_id parameter, so this report might be incorrect or : associated with a different type of issue, e.g. a SQL error from a query : with a non-numeric value. See above. I'm guessing based on volume alone, that he is doing no real testing beyond single backticks. So far I don't believe any of his vulnerability reports include working examples other than a few of the XSS issues. All the SQL injections are left as =[SQL] with no working exploit. From coley at linus.mitre.org Sun Nov 27 03:59:07 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Sun Nov 27 04:01:38 2005 Subject: [VIM] Confirmation (source inspection) of various r0t-discovered issues In-Reply-To: References: <200511270805.jAR85w5q018504@cairo.mitre.org> Message-ID: On Sun, 27 Nov 2005, security curmudgeon wrote: > Yep, we've been curious about this. 99% of his finds are simple cut/paste > XSS or single back tick SQL injection testing, so it isn't surprising on > one hand. The volume of products is interesting though. It made me wonder > if someone had finally scripted something out to wget, untar, configure, > make, make install and auto-paros (or the equiv) the software. It definitely isn't source inspection. Assuming his findings are generally accurate, there were a couple places where he found attacks that don't have surface-level vulnerable points in the code, e.g. one script used callback functions that were initialized deep in an include file. One of these days when I write down my thoughts on vulnerability complexity, I'm gonna talk about how some vulns with complex execution paths in the code - not findable by code analysis tools - can be subject to the most obvious attacks, indicating the lack of basic testing. A "complex" vuln should have complex code paths *and* complex attacks, but I digress. > One of the finds had what I took to be vendor confirmation. There was a > freshmeat announce for a new version of software that fixed XSS and SQL > Injections. It was released a day after r0t's mail to us and secunia (not > sure who else he is mailing), was the next logical version, etc. I've been burned once or twice by this assumption, so I don't call it vendor confirmation unless the original disclosure claimed vendor coordination, which is still slightly tenuous, but I think I'm more anal about this than most. Coincidences are rare, but they happen. > : For CVE-2005-3833 - Tunez "songinfo.php?song_id=[SQL]" SQL injection - > : source code inspection of songinfo.php suggests that an addslashes() is > : performed on the song_id parameter, so this report might be incorrect or > : associated with a different type of issue, e.g. a SQL error from a query > : with a non-numeric value. > > See above. I'm guessing based on volume alone, that he is doing no real > testing beyond single backticks. One of his XSS examples was hex-encoded, but I wonder if that was just coincidence. > So far I don't believe any of his > vulnerability reports include working examples other than a few of the > XSS issues. All the SQL injections are left as =[SQL] with no working > exploit. Yes, the lack of working examples is interesting - sometimes he doesn't even include a simple demo URL, although he frequently abstracts them out to the relevant scripts and parameters. I like the "[SQL]" and other shorthands when researchers use them, but on the other hand it hides whether they *really* found SQL injection or if they just provided an invalid value that caused a non-injectable SQL error. - Steve From jericho at attrition.org Sun Nov 27 10:26:54 2005 From: jericho at attrition.org (security curmudgeon) Date: Sun Nov 27 10:26:58 2005 Subject: [VIM] Confirmation (source inspection) of various r0t-discovered issues In-Reply-To: References: <200511270805.jAR85w5q018504@cairo.mitre.org> Message-ID: : It definitely isn't source inspection. Assuming his findings are Yep, the volume would make that near impossible unless it was a sizable team. : > One of the finds had what I took to be vendor confirmation. There was a : > freshmeat announce for a new version of software that fixed XSS and SQL : > Injections. It was released a day after r0t's mail to us and secunia (not : > sure who else he is mailing), was the next logical version, etc. : : I've been burned once or twice by this assumption, so I don't call it : vendor confirmation unless the original disclosure claimed vendor : coordination, which is still slightly tenuous, but I think I'm more anal : about this than most. Coincidences are rare, but they happen. I agree. Without source code inspection of the new version and comparing with the old, basically impossible to verify it either. Until we get a lot more volunteers with coding background, this will likely be a hurdle for VDBs. : > See above. I'm guessing based on volume alone, that he is doing no real : > testing beyond single backticks. : : One of his XSS examples was hex-encoded, but I wonder if that was just : coincidence. I can't find the URL now, but a few months ago someone posted a page with a few dozen XSS variants, designed for cut/paste testing. It would be fairly trivial to have two or three standard XSS attempts for easy testing. : Yes, the lack of working examples is interesting - sometimes he doesn't : even include a simple demo URL, although he frequently abstracts them : out to the relevant scripts and parameters. I like the "[SQL]" and : other shorthands when researchers use them, but on the other hand it : hides whether they *really* found SQL injection or if they just provided : an invalid value that caused a non-injectable SQL error. Right. That is why I like when they give a sample URL that includes [SQL] or preferably a single back tick, so we have a better idea of what they tested. From jericho at attrition.org Sun Nov 27 11:19:20 2005 From: jericho at attrition.org (security curmudgeon) Date: Sun Nov 27 11:19:22 2005 Subject: [VIM] Confirmation (source inspection) of various r0t-discovered issues In-Reply-To: References: <200511270805.jAR85w5q018504@cairo.mitre.org> Message-ID: : : One of his XSS examples was hex-encoded, but I wonder if that was just : : coincidence. : : I can't find the URL now, but a few months ago someone posted a page : with a few dozen XSS variants, designed for cut/paste testing. It would : be fairly trivial to have two or three standard XSS attempts for easy : testing. Sullo had the URL =) http://sec.drorshalev.com/dev/xss/xssTricks.htm From jericho at attrition.org Sun Nov 27 13:23:02 2005 From: jericho at attrition.org (security curmudgeon) Date: Sun Nov 27 13:23:05 2005 Subject: [VIM] welcome Jake Kouns Message-ID: Jake is one of the three project leaders of OSVDB. From jkouns at opensecurityfoundation.org Sun Nov 27 13:45:41 2005 From: jkouns at opensecurityfoundation.org (jkouns) Date: Sun Nov 27 13:48:16 2005 Subject: [VIM] Confirmation (source inspection) of various r0t-discovered issues (fwd) In-Reply-To: References: Message-ID: <4389FED5.5050109@opensecurityfoundation.org> Considering we were receiving an email every other hour for the last couple days I also had "taken a small interest".... Late last night he posted a message: http://pridels.blogspot.com/2005/11/tapat.html Again, with that small interest I wanted to know what it said and I figured it would be a quick translation. However, before I could even start to translate it, I needed to figure out what language it is! Looking at the 14 year old bio, he states: Location: Turku : Finland Trying to translate Finnish to English didn't go over very well, but the first word was translated to "Accident" http://www.tranexp.com:2000/InterTran?type=url&url=http%3A%2F%2Fpridels.blogspot.com%2F&text=&from=fin&to=eng Trying to figure out if there is another language... Pasted the post into the http://translation.langenberg.com/ Xerox -- Language Identifier/Guesser They guess: Latvian_cp1257 Fuzzums -- Language Identifier/Guesser They guess: Latvian 71.91% Finnish 58.51% Latin 54.5% Indonesian 53.33% Swedish 51.12% Italian 49.72% French 48.91% Doing a Latvian translation produced absolutely nothing. So, this small interest has wasted a good amount of time. If anyone figures out what was posted, let me know. For some reason I am still curious. --Jake > ---------- Forwarded message ---------- > From: Steven M. Christey > To: vim@attrition.org > Date: Sun, 27 Nov 2005 03:05:58 -0500 (EST) > Reply-To: Vulnerability Information Managers > Subject: [VIM] Confirmation (source inspection) of various > r0t-discovered issues > > > I've taken a small interest in observing r0t (r0t3d3Vil) since he's > done a whole lot of reports in the past couple of days in software > that hasn't been reported vulnerable before... plus his blog profile > says he's 14. > > Most of his analyses are of for-purchase products, so I couldn't check > those. At least one demo site for one vendor had been tested by him, > as his leftover XSS attempts indicated :-/ so some of his results > might be coming from tests of vendor demo sites. > > Anyway, for some products with source available, I was able to confirm > - by source inspection only - several recent issues. > > > CVE-2005-3834 > > searchFor is directly inserted into a $title variable. > > CVE-2005-3846 > > line 205 news.php - > $where="AND c.category_id=".$_REQUEST['category'].""; > > CVE-2005-3853 > > Multiple locations exist, including the title() function where a > $_GET['id'] (line 174) is fed directly into a $query variable without > quoting (line 179), which is then fed to mysql_query() (line 180). > > source code review of 1.3 shows that snews.php is the affected file. > > > For CVE-2005-3833 - Tunez "songinfo.php?song_id=[SQL]" SQL injection - > source code inspection of songinfo.php suggests that an addslashes() > is performed on the song_id parameter, so this report might be > incorrect or associated with a different type of issue, e.g. a SQL > error from a query with a non-numeric value. > > - Steve > > > > > ====================================================== > Name: CVE-2005-3834 > Status: Candidate > URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3834 > Reference: > MISC:http://pridels.blogspot.com/2005/11/tunez-sql-and-xss-vuln.html > Reference: BID:15548 > Reference: URL:http://www.securityfocus.com/bid/15548 > Reference: OSVDB:21063 > Reference: URL:http://www.osvdb.org/21063 > Reference: SECUNIA:17692 > Reference: URL:http://secunia.com/advisories/17692 > > Cross-site scripting (XSS) vulnerability in search.php in Tunez 1.21 > and earlier allows remote attackers to inject arbitrary web script or > HTML via the searchFor parameter. > > > ====================================================== > Name: CVE-2005-3846 > Status: Candidate > URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3846 > Reference: > MISC:http://pridels.blogspot.com/2005/11/fantastic-news-category-sql-inj.html > > Reference: FRSIRT:ADV-2005-2595 > Reference: URL:http://www.frsirt.com/english/advisories/2005/2595 > > SQL injection vulnerability in news.php in Fantastic News 2.1.1 and > earlier allows remote attackers to execute arbitrary SQL commands via > the category parameter. > > > ====================================================== > Name: CVE-2005-3853 > Status: Candidate > URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3853 > Reference: > MISC:http://pridels.blogspot.com/2005/11/snews-13-sql-injection.html > Reference: OSVDB:21093 > Reference: URL:http://www.osvdb.org/21093 > Reference: SECUNIA:17688 > Reference: URL:http://secunia.com/advisories/17688 > > SQL injection vulnerability in snews.php in sNews 1.3 and earlier > allows remote attackers to execute arbitrary SQL commands via the (1) > id and (2) category parameters to index.php. > > > > > From coley at linus.mitre.org Sun Nov 27 14:58:10 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Sun Nov 27 15:00:41 2005 Subject: [VIM] Confirmation (source inspection) of various r0t-discovered issues In-Reply-To: References: <200511270805.jAR85w5q018504@cairo.mitre.org> Message-ID: On Sun, 27 Nov 2005, security curmudgeon wrote: > : It definitely isn't source inspection. Assuming his findings are > > Yep, the volume would make that near impossible unless it was a sizable > team. I have an extremely crude PHP scanner that nonetheless is effective in finding blatantly obvious problems, which most PHP apps have... > I agree. Without source code inspection of the new version and comparing > with the old, basically impossible to verify it either. Until we get a lot > more volunteers with coding background, this will likely be a hurdle for > VDBs. ... and a great argument for why we should work together and share results ;-) > : One of his XSS examples was hex-encoded, but I wonder if that was just > : coincidence. > > I can't find the URL now, but a few months ago someone posted a page with > a few dozen XSS variants, designed for cut/paste testing. It would be > fairly trivial to have two or three standard XSS attempts for easy > testing. Good point. - Steve From coley at mitre.org Tue Nov 29 01:04:42 2005 From: coley at mitre.org (Steven M. Christey) Date: Tue Nov 29 01:07:29 2005 Subject: [VIM] SourceWell - minor version number oddities and independent confirm Message-ID: <200511290604.jAT64gN5001240@cairo.mitre.org> Regarding the SourceWell SQL injection in index.php via cnt: http://pridels.blogspot.com/2005/11/sourcewell-sql-inj-vuln.html The SourceWell front page says the latest version is 1.1.3, but the online changelog, available downloads, and new release announcements only go up to 1.1.2. I did confirm r0t's analysis by source inspection on 1.1.2. Inspection of install.php shows a requirement for register_globals. Then index.php has: [84] $limit = $cnt.",".$config_show_appsperpage; [124] $query = "SELECT $columns FROM $tables WHERE $where ORDER BY $order LIMIT $limit"; [126] appdat($query); $query is later fed into a query method call on an instance of the DB_Sql class (in the default configuration anyway). - Steve From coley at mitre.org Tue Nov 29 04:00:42 2005 From: coley at mitre.org (Steven M. Christey) Date: Tue Nov 29 04:03:22 2005 Subject: [VIM] More confirmed r0t issues Message-ID: <200511290900.jAT90gA1002382@cairo.mitre.org> The latest products being investigated by r0t have more freeware, so here's my take on some of 'em. I'll need to cut down on this stuff though. Even the obvious things can take more time than I usually have! :) He's definitely doing only surface-level, incomplete research. Some of these products had dozens of attack vectors when you looked at the source. CVEs listed at end of the email. CVE-2005-3882 - Line 7 feeds $GET['id'] into mysql_query(). CVE-2005-3881 - Uninitialized $searchStr is fed directly into mysql_query() on line 17. CVE-2005-3877 - messages.php - line 525, print_message() called by print_nav() with $mid as set by GPC vars. list.php - $folder_id initialized by GPC in line 12, injected into $query var lines 49 and 51, fed into mysql_query() line 53). CVE-2005-3875 - including line 176 in send.php: $sql = "SELECT message, sender FROM connector_message WHERE messageid = " . $_GET['messageid']; and the delete action on line 21 of messages.php: $sql = "DELETE FROM connector_message WHERE messageid=" . $_GET['messageid']; CVE-2005-3874 - index.php calls netzbrett_main() (netzbr.php) which calls print_entry($GLOBALS["p_entry"]) which calls read_entry() to mysql_read_entry() which inserts the entry number into a SELECT clause which is fed to mysql_query. CVE-2005-3871 - ACCURACY: some of these attack vectors were confirmed via source code inspection of a newer product version - v1.0.0rc1 - as obtained from SourceForge. The other vectors might have been eliminated between 0.9.9rc3 and v1.0.0rc1. CVE-2005-3870 - ACCURACY: some of these attack vectors were confirmed via source code inspection of a newer product version - v1.0.0rc1 - as obtained from SourceForge. The other vectors might have been eliminated between 0.9.9rc3 and v1.0.0rc1. ========================================================================== ====================================================== Name: CVE-2005-3870 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3870 Reference: MISC:http://pridels.blogspot.com/2005/11/edmobbs-sql-inj-vuln.html Reference: BID:15589 Reference: URL:http://www.securityfocus.com/bid/15589 Reference: FRSIRT:ADV-2005-2621 Reference: URL:http://www.frsirt.com/english/advisories/2005/2621 Reference: SECUNIA:17726 Reference: URL:http://secunia.com/advisories/17726 Multiple SQL injection vulnerabilities in edmobbs9r.php in edmoBBS 0.9 and earlier allow remote attackers to execute arbitrary SQL commands via the (1) table and (2) messageID parameters. ====================================================== Name: CVE-2005-3871 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3871 Reference: MISC:http://pridels.blogspot.com/2005/11/jbb-sql-inj-vuln.html Reference: BID:15590 Reference: URL:http://www.securityfocus.com/bid/15590 Reference: FRSIRT:ADV-2005-2620 Reference: URL:http://www.frsirt.com/english/advisories/2005/2620 Reference: SECUNIA:17727 Reference: URL:http://secunia.com/advisories/17727 Multiple SQL injection vulnerabilities in Joels Bulletin board (JBB) 0.9.9rc3 and earlier allow remote attackers to execute arbitrary SQL commands via the (1) nr parameter in topiczeigen.php, (2) forum and (3) zeigeseite parameters in showforum.php, (4) forum parameter in newtopic.php, and (5) tidnr parameter in neuerbeitrag.php. ====================================================== Name: CVE-2005-3874 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3874 Reference: MISC:http://pridels.blogspot.com/2005/11/netzbrett-151-sql-inj-vuln.html Reference: BID:15593 Reference: URL:http://www.securityfocus.com/bid/15593 Reference: FRSIRT:ADV-2005-2611 Reference: URL:http://www.frsirt.com/english/advisories/2005/2611 Reference: SECUNIA:17742 Reference: URL:http://secunia.com/advisories/17742 SQL injection vulnerability in netzbr.php in Netzbrett 1.5.1 and earlier allows remote attackers to execute arbitrary SQL commands via the p_entry parameter in an entry command to index.php. ====================================================== Name: CVE-2005-3875 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3875 Reference: MISC:http://pridels.blogspot.com/2005/11/enterprise-connector-sql-inj-vuln.html Reference: FRSIRT:ADV-2005-2602 Reference: URL:http://www.frsirt.com/english/advisories/2005/2602 Reference: SECUNIA:17743 Reference: URL:http://secunia.com/advisories/17743 Multiple SQL injection vulnerabilities in Enterprise Connector 1.0.2 and earlier allow remote attackers to execute arbitrary SQL commands via the messageid parameter in (1) send.php or (2) a delete action in messages.php. ====================================================== Name: CVE-2005-3877 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3877 Reference: MISC:http://pridels.blogspot.com/2005/11/sdms-20-sql-inj-vuln.html Reference: FRSIRT:ADV-2005-2614 Reference: URL:http://www.frsirt.com/english/advisories/2005/2614 Reference: SECUNIA:17746 Reference: URL:http://secunia.com/advisories/17746 Multiple SQL injection vulnerabilities in Simple Document Management System (SDMS) 2.0-CVS and earlier allow remote attackers to execute arbitrary SQL commands via the (1) folder_id parameter in list.php and (2) mid parameter in a view action to messages.php. ====================================================== Name: CVE-2005-3881 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3881 Reference: MISC:http://pridels.blogspot.com/2005/11/altantisfaq-sql-inj-vuln.html Reference: FRSIRT:ADV-2005-2624 Reference: URL:http://www.frsirt.com/english/advisories/2005/2624 SQL injection vulnerability in search.php in AltantisFAQ Knowledge Base Software 2.03 and earlier allows remote attackers to execute arbitrary SQL commands via the searchStr parameter. ====================================================== Name: CVE-2005-3882 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3882 Reference: MISC:http://pridels.blogspot.com/2005/11/faqring-30-sql-inj-vuln.html Reference: FRSIRT:ADV-2005-2625 Reference: URL:http://www.frsirt.com/english/advisories/2005/2625 SQL injection vulnerability in answer.php in FAQSystems FAQRing Knowledge Base Software 3.0 and earlier allows remote attackers to execute arbitrary SQL commands via the id parameter. From coley at linus.mitre.org Tue Nov 29 23:07:08 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue Nov 29 23:10:02 2005 Subject: [VIM] Re: Confirmation of BosDates vulnerability? (fwd) Message-ID: Re: http://pridels.blogspot.com/2005/11/bosdates-v40-sql-vuln.html (CVE-2005-3911) The BosDates developer apparently left an acknowledgement on r0t's blog, so I asked him to confirm and he did. See below. - Steve ---------- Forwarded message ---------- Date: Tue, 29 Nov 2005 21:53:08 -0600 From: Don Boston To: Steven M. Christey Subject: Re: Confirmation of BosDates vulnerability? At 09:27 PM 11/29/2005, you wrote: >Is this the case? Has the issue been fixed? I could not find >information on your web site. Yes, I sent out a mass email to all of my clients who use the product to inform them of the corrected calendar.php file. A copy of the email is below: ---------------------------------------------------------------------------------------- To: XXXXXX@bosdev.com Subject: BosDev - BosDate Security Issue From: announcements@bosdev.com Date: Tue, 29 Nov 2005 11:13:52 -0500 SECURITY NOTICE FOR BOSDATES 4.X Thank you for taking the time to read my email, I know how busy you are and I appreciate your time. A security flaw has been discovered in BosDates version 4.x which can potentially open the system to malicious SQL injections. The report: "r0t has reported two vulnerabilities in BosDates, which can be exploited by malicious people to conduct SQL injection attacks. Input passed to the "year" and "category" parameters in "calendar.php" isn't properly sanitised before being used in a SQL query. This can be exploited to manipulate SQL queries by injecting arbitrary SQL code." We have released a patch for this issue, to correct it. The issue was first discovered on the 25th of this month, and reported today. BosDev immediately fixed the issue and now suggests you upgrade your calendar script. To obtain the latest build, simply login to our downloads section at http://www.bosdev.com/download/ Once you have downloaded the package, upload the /calendar.php file to your calendar directory. There have been no reported attacks on any customer sites at this time. Do not reply to this message, it will go to a non-existant account. Please feel free to send any comments to support@bosdev.com instead. ------------------------------------------------------------------------------------------- Thank you for following up on this issue. Don Boston http://www.bosdev.com From jericho at attrition.org Tue Nov 29 23:12:09 2005 From: jericho at attrition.org (security curmudgeon) Date: Tue Nov 29 23:12:12 2005 Subject: [VIM] the latest r0t advisory flood Message-ID: So far, it seems he is not mailing each VDB with every release. I have noticed Secunia received a handful we did not, and based on my backlog of incoming mail, I am guessing Secunia did not receive mail about some that OSVDB did (or they are 5 days behind on adding to their DB, as I am!). Curious if this is intentional.. From coley at linus.mitre.org Tue Nov 29 23:15:49 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Tue Nov 29 23:18:29 2005 Subject: [VIM] the latest r0t advisory flood In-Reply-To: References: Message-ID: Hopefully history will prove right again and this guy will burn himself out in a week or two ;-) The CVE to-do list is full of his recent posts. - Steve From coley at mitre.org Wed Nov 30 00:57:17 2005 From: coley at mitre.org (Steven M. Christey) Date: Wed Nov 30 00:59:58 2005 Subject: [VIM] Vendor dispute of OvBB issue (r0t) - seems legit Message-ID: <200511300557.jAU5vHde012042@cairo.mitre.org> The front page of http://www.ovbb.org has a dispute of the recent r0t-reported OvBB issues: November 29, 2005 There have been several vulnerability reports released in the past week regarding OvBB, that claim there are at least two instances of user input being used without being properly sanitized. However, these reports are completely unsubstantial. To be clear: there are no known security holes in the system; plenty of bugs, but none that are known to pose a security risk. If you have any questions or comments regarding this, don't hesitate to contact me. I did some source review and their claim seems legit: thread.php: $iThreadID = mysql_real_escape_string($_REQUEST['threadid']); ... $sqlResult = sqlquery("SELECT thread.title, thread.parent, COUNT(post.id) AS postcount, thread.poll, thread.open, thread.visible, thread.sticky, thread.notes FROM thread LEFT JOIN post ON (post.parent = thread.id) WHERE thread.id=$iThreadID GROUP BY thread.title"); profile.php: $iUserID = mysql_real_escape_string($_REQUEST['userid']); ... $sqlResult = sqlquery("SELECT * FROM member WHERE id=$iUserID"); NOTE however that there is no verification that threadid and userid are numeric, which could mean that r0t might have triggered an error of some sort. - Steve From coley at linus.mitre.org Wed Nov 30 01:17:07 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Wed Nov 30 01:19:46 2005 Subject: [VIM] Alternate theory on OvBB "SQL" vulnerability (fwd) Message-ID: We'll see what the vendor says... Maybe one day I'll actually get PHP on some system and check this stuff out for reals :) ---------- Forwarded message ---------- Date: Wed, 30 Nov 2005 01:16:02 -0500 (EST) From: Steven M. Christey To: jon@ovbb.org Cc: coley@mitre.org Subject: Alternate theory on OvBB "SQL" vulnerability Hello, I'm a vulnerability researcher for CVE, a standard naming scheme for vulnerabilities. I looked at the source code for 0.08a and see how you used mysql_real_escape_string to sanitize the parameters in question. However, you don't check that they are numeric. If someone has PHP verbose errors on, and you provide the parameters with a non-numeric argument, then would it generate a SQL error that complains about the bad data type? This could be what r0t saw that made him think it's SQL injection. This is a common diagnostic error made by many beginning researchers. - Steve From coley at mitre.org Wed Nov 30 19:01:05 2005 From: coley at mitre.org (Steven M. Christey) Date: Thu Dec 1 20:12:53 2005 Subject: [VIM] Multiple IBM Tivoli documents leading to same issue Message-ID: <200512010001.jB101504017064@cairo.mitre.org> FYI, iDEFENSE noticed some possible CVE dupes regarding IBM Tivoli Directory Server. These dupes arose from different IBM documents, one with a very vague description, and the other with a more detailed description, and neither seeming to refer to the other. I did some digging and they lead to the same APARs. Maybe this will help save other people some analytical effort and/or prevent their own dupes. See the references in CVE-2005-3567 below. - Steve ====================================================== Name: CVE-2005-3567 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3567 Reference: CONFIRM:http://www-1.ibm.com/support/docview.wss?rs=767&context=SSVJJU&dc=D400&uid=swg24010819&loc=en_US&cs=UTF-8&lang=en Reference: CONFIRM:http://www-1.ibm.com/support/docview.wss?uid=swg21222159 Reference: CONFIRM:http://www-1.ibm.com/support/docview.wss?uid=isg1SSRVAIX53SECUR081510_247 Reference: AIXAPAR:IO02697 Reference: URL:http://www-1.ibm.com/support/search.wss?rs=0&q=IO02697&apar=only Reference: AIXAPAR:IO02714 Reference: URL:http://www-1.ibm.com/support/search.wss?rs=0&q=IO02714&apar=only Reference: CERT-VN:VU#194753 Reference: URL:http://www.kb.cert.org/vuls/id/194753 Reference: FRSIRT:ADV-2005-2356 Reference: URL:http://www.frsirt.com/english/advisories/2005/2356 Reference: SECTRACK:1015171 Reference: URL:http://securitytracker.com/id?1015171 Reference: SECUNIA:17484 Reference: URL:http://secunia.com/advisories/17484 slapd daemon in IBM Tivoli Directory Server (ITDS) 5.2.0 and 6.0.0 binds using SASL EXTERNAL, which allows attackers to bypass authentication and modify and delete directory data via unknown attack vectors. ====================================================== Name: CVE-2005-3898 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3898 ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2005-3567. Reason: This candidate is a reservation duplicate of CVE-2005-3567. Notes: All CVE users should reference CVE-2005-3567 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage. From coley at linus.mitre.org Wed Nov 30 19:39:50 2005 From: coley at linus.mitre.org (Steven M. Christey) Date: Thu Dec 1 20:14:06 2005 Subject: [VIM] RE: Alternate theory on OvBB "SQL" vulnerability (fwd) Message-ID: Vindication! woo-hoo! :) ---------- Forwarded message ---------- Date: Wed, 30 Nov 2005 18:37:38 -0600 From: J. Freeman To: Steven M. Christey Subject: RE: Alternate theory on OvBB "SQL" vulnerability Hi Steve, Okay, I've looked this over, and I think I understand what's happened. Like you suggested, the invalid SQL caused an error to be generated. (This even happens when error reporting is kept at its default.) Said error triggered my database error handler, the output of which r0t received. If that's all there was to it, he would have only received a message saying there's something wrong with the database--not enough to presume an exploit had been made. HOWEVER... before publishing this latest version, I forgot to turn *off* verbose output in said handler (which essentially shows all previous SQL queries). r0t probably saw all those previous queries and assumed he had successfully exploited a vulnerability. Anyway, I'll fix this by typecasting the user's input to an integer, as well as turning OFF my handler's verbose output. Thanks for helping me figure this out. How did you hear about this? Regards, J. Freeman -----Original Message----- From: Steven M. Christey [mailto:coley@mitre.org] Sent: Wednesday, November 30, 2005 12:16 AM To: jon@ovbb.org Cc: coley@mitre.org Subject: Alternate theory on OvBB "SQL" vulnerability Hello, I'm a vulnerability researcher for CVE, a standard naming scheme for vulnerabilities. I looked at the source code for 0.08a and see how you used mysql_real_escape_string to sanitize the parameters in question. However, you don't check that they are numeric. If someone has PHP verbose errors on, and you provide the parameters with a non-numeric argument, then would it generate a SQL error that complains about the bad data type? This could be what r0t saw that made him think it's SQL injection. This is a common diagnostic error made by many beginning researchers. - Steve -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.13.10/189 - Release Date: 11/30/2005 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.13.10/189 - Release Date: 11/30/2005 From coley at mitre.org Wed Nov 30 21:12:17 2005 From: coley at mitre.org (Steven M. Christey) Date: Thu Dec 1 20:15:29 2005 Subject: [VIM] Vendor ACK for Orca Blog issue Message-ID: <200512010212.jB12CHD9017736@cairo.mitre.org> Re: http://pridels.blogspot.com/2005/11/orca-blog-sql-inj-vuln.html Vendor ACKed issue on r0t's web site, blog, but ack is also at http://www.greywyvern.com/orca#blog "Changelog: 1.3b to 1.3c Patch for Secunia advisory #17804 - MySQL Injection" - Steve From jericho at attrition.org Wed Nov 30 21:32:01 2005 From: jericho at attrition.org (security curmudgeon) Date: Thu Dec 1 20:15:31 2005 Subject: [VIM] Re: [Full-disclosure] Torrential 1.2 getdox.php Directory Traversal In-Reply-To: References: Message-ID: Hi Shell, : I was poking around my own server because I had an installation of : torrential and found this vuln. The problem lies in getdox.php. It works : by taking an argument after a "/". This specifies a file. The DOX folder : that it grabs the files from is located int /dox such that / is the : directory that the main index is in. Now, you can give it the parameter : of /(any file) and it will fetch that file. : : EXAMPLES: : http://www.example.com/torrential/dox/getdox.php/../forums.php (goes : to the forums page) : http://www.example.com/torrential/dox/getdox.php/../../index.html : (goes to http://www.example.com/index.html in this case) It isn't clear if this can be used to gain access to sensitive or restricted files. The examples above both make it look like you would normally have access to the forums.php or index.html files anyway. Will this traverse out of the web root? Brian OSVDB.org From coley at mitre.org Wed Nov 30 22:18:48 2005 From: coley at mitre.org (Steven M. Christey) Date: Thu Dec 1 20:15:44 2005 Subject: [VIM] Vendor ACK for PHPAlbum r0t issue Message-ID: <200512010318.jB13ImLI018058@cairo.mitre.org> It seems like I'm concentrating on r0t a lot, but it's just coincidence related to volume ;-) MISC:http://pridels.blogspot.com/2005/11/phpalbum-local-file-include-vuln.html The download page includes acknowledgement: http://www.phpalbum.net/dw 30.11.2005 says "- bugfix release fixed multiple security vulnerabilities, reported here http://pridels.blogspot.com/2005/11/phpalbum-local-file-include-vuln.html" - Steve From coley at mitre.org Wed Nov 30 22:53:00 2005 From: coley at mitre.org (Steven M. Christey) Date: Thu Dec 1 20:16:27 2005 Subject: [VIM] blogBuddies XSS issues include MagpieRSS Message-ID: <200512010353.jB13r0GE018216@cairo.mitre.org> FYI, regarding the recent blogbuddies XSS issues (CVE-2005-3954, CVE-2005-3955). blogbuddies includes a separate product, magpieRSS, and that's what some of the reported vectors are in. The same magpie vectors were listed in a PHP-Nuke issue (CVE-2005-1695) - Steve ====================================================== Name: CVE-2005-1695 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1695 Reference: BUGTRAQ:20050521 [SECURITYREASON.COM] PostNuke XSS 0.760{RC2,RC3} Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=111670482500552&w=2 Reference: BUGTRAQ:20050521 [SECURITYREASON.COM] PostNuke XSS and Full path disclosure Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=111670506926649&w=2 Reference: CONFIRM:http://news.postnuke.com/modules.php?op=modload&name=News&file=article&sid=2691 Multiple cross-site scripting (XSS) vulnerabilities in the RSS module in PostNuke 0.750 and 0.760RC2 and RC3 allow remote attackers to inject arbitrary web script or HTML via the (1) rss_url parameter to magpie_slashbox.php, or the url parameter to (2) magpie_simple.php or (3) magpie_debug.php. ====================================================== Name: CVE-2005-3954 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3954 Reference: CONFIRM:http://sourceforge.net/tracker/index.php?func=detail&aid=1366743&group_id=127552&atid=708847 Reference: BID:15555 Reference: URL:http://www.securityfocus.com/bid/15555 Reference: SECUNIA:17741 Reference: URL:http://secunia.com/advisories/17741 Cross-site scripting (XSS) vulnerability in blogBuddies 0.3 allows remote attackers to inject arbitrary web script or HTML via the u parameter to index.php. ====================================================== Name: CVE-2005-3955 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3955 Reference: CONFIRM:http://sourceforge.net/tracker/index.php?func=detail&aid=1366743&group_id=127552&atid=708847 Reference: BID:15555 Reference: URL:http://www.securityfocus.com/bid/15555 Reference: SECUNIA:17741 Reference: URL:http://secunia.com/advisories/17741 Multiple cross-site scripting (XSS) vulnerabilities in MagpieRSS 7.1, as used in blogBuddies 0.3 and possibly other products, allow remote attackers to inject arbitrary web script or HTML via the (1) url parameter to magpie_debug.php; and rss_url parameter to (2) magpie_slashbox.php and (3) simple_smarty.php.