From coley at mitre.org Thu Jan 5 02:12:32 2006 From: coley at mitre.org (Steven M. Christey) Date: Thu, 5 Jan 2006 02:12:32 -0500 (EST) Subject: [VIM] Open Letter on the Interpretation of "Vulnerability Statistics" Message-ID: <200601050712.k057CWe3017342@cairo.mitre.org> Open Letter on the Interpretation of "Vulnerability Statistics" --------------------------------------------------------------- Author: Steve Christey, CVE Editor Date: January 4, 2006 All, As the new year begins, there will be many temptations to generate, comment, or report on vulnerability statistics based on totals from 2005. The original reports will likely come from publicly available Refined Vulnerability Information (RVI) sources - that is, vulnerability databases (including CVE/NVD), notification services, and periodic summary producers. RVI sources collect unstructured vulnerability information from Raw Sources. Then, they refine, correlate, and redistribute the information to others. Raw sources include mailing lists like Bugtraq, Vulnwatch, and Full-Disclosure, web sites like PacketStorm and Securiteam, blogs, conferences, newsgroups, direct emails, etc. In my opinion, RVI sources are still a year or two away from being able to produce reliable, repeatable, and COMPARABLE statistics. In general, consumers should treat current statistics as suggestive, not conclusive. Vulnerability statistics are difficult to interpret due to several factors: - VARIATIONS IN EDITORIAL POLICY. An RVI source's editorial policy dictates HOW MANY vulnerabilities are reported, and WHICH vulnerabilities are reported. RVIs have widely varying policies. You can't even compare an RVI against itself, unless you can be sure that its editorial policy has not changed within the relevant data set. The editorial policies of RVIs seem to take a few years before they stabilize, and there is evidence that they can change periodically. - FRACTURED VULNERABILITY INFORMATION. Each RVI source collects its information from its own list of raw sources - web sites, mailing lists, blogs, etc. RVIs can also use other RVIs as sources. Apparently for competitive reasons, some RVIs might not identify the raw source that was used for a vulnerability item, which is one aspect of what I refer to as the provenance problem. Long gone are the days when a couple mailing lists or newsgroups were the raw source for 90% of widely available vulnerability information. Based on what I have seen, the provenance problem is only going to get worse. - LACK OF COMPLETE CROSS-REFERENCING BETWEEN RVI SOURCES. No RVI has an exhaustive set of cross-references, so no RVI can be sure that it is 100% comprehensive, even with respect to its own editorial policy. Some RVIs compete with each other directly, so they don't cross-reference each other. Some sources could theoretically support all public cross-references - most notably OSVDB and CVE - but they do not, due to resource limitations or other priorities. - UNMEASURABLE RESEARCH COMMUNITY BIAS. Vulnerability researchers vary widely in skill sets, thoroughness, preference for certain vulnerability types or product classes, and so on. This collectively produces a bias that is not currently measurable against the number of latent vulnerabilities that actually exist. Example: web browser vulnerabilities were once thought to belong to Internet Explorer only, until people actually started researching other browsers; many elite researchers concentrate on a small number of operating systems or product classes; basic SQL injection and XSS are very easy to find manually; etc. - UNMEASURABLE DISCLOSURE BIAS. Vendors and researchers vary widely in their disclosure models, which creates an unmeasurable bias. For example, one vendor might hire an independent auditor and patch all reported vulnerabilities without publicly announcing any of them, or a different vendor might publish advisories even for very low-risk issues. One researcher might disclose without coordinating with the vendor at all, whereas another researcher might never disclose an issue until a patch is provided, even if the vendor takes an inordinate amount of time to respond. Note that many large-scale comparisons, such as "Linux vs. Windows," can not be verified due to unmeasurable bias, and/or editorial policy of the core RVI that was used to conduct the comparison. EDITORIAL POLICY VARIATIONS --------------------------- This is just a sample of variations in editorial policy. There are legitimate reasons for each variation, usually due to audience needs or availability of analytical resources. COMPLETENESS (what is included): 1) SEVERITY. Some RVIs do not include very low-risk items such as a bug that causes path disclosure in an error message in certain non-operational configurations. Secunia and SecurityFocus do not do this, although they might note this when other issues are identified. Others include low-risk issues, such as CVE, ISS X-Force, US-CERT Security Bulletins, and OSVDB. 2) VERACITY. Some RVIs will only publish vulnerabilities when they are confident that the original, raw report is legitimate - or if they're verified it themselves. Others will publish reports when they are first detected from the raw sources. Still others will only publish reports when they are included in other RVIs, which makes them subject to the editorial policies of those RVIs unless care is taken. For example, US-CERT's Vulnerability Notes have a high veracity requirement before they are published; OSVDB and CVE have a lower requirement for veracity, although they have correction mechanisms in place if veracity is questioned, and CVE has a two-stage approach (candidates and entries). 3) PRODUCT SPACE. Some RVIs might omit certain products that have very limited distribution, are in the beta development stage, or are not applicable to the intended audience. For example, version 0.0.1 of a low-distribution package might be omitted, or if the RVI is intended for a business audience, video game vulnerabilities might be excluded. On the other hand, some "beta" products have extremely wide distribution. 4) OTHER VARIATIONS. Other variations exist but have not been studied or categorized at this time. One example, though, is historical completeness. Most RVIs do not cover vulnerabilities before the RVI was first launched, whereas others - such as CVE and OSVDB - can include issues that are older than the RVI itself. As another example: a few years ago, Neohapsis made an editorial decision to omit most PHP application vulnerabilities from their summaries, if they were obscure products, or if the vulnerability was not exploitable in a typical operational configuration. ABSTRACTION (how vulnerabilities are "counted"): 5) VULNERABILITY TYPE. Some RVIs distinguish between types of vulnerabilities (e.g. buffer overflow, format string, symlink, XSS, SQL injection). CVE, OSVDB, ISS X-Force, and US-CERT Vulnerability Notes perform this distinction; Secunia, FrSIRT, and US-CERT Cyber Security Bulletins do not. Bugtraq IDs vary. As vulnerability classification becomes more detailed, there is more room for variation (e.g. integer overflows and off-by-ones might be separated from "classic" overflows). 6) REPLICATION. Some RVIs will produce multiple records for the same core vulnerability, even based on the RVI's own definition. Usually this is done when the same vulnerability affects multiple vendors, or if important information is released at a later date. Secunia and US-CERT Security Bulletins use replication; so might vendor advisories (for each supported distribution). OSVDB, Bugtraq ID, CVE, US-CERT Vulnerability Notes, and ISS X-Force do not - or, they use different replication than others. Replication's impact on statistics is not well understood. 7) OTHER VARIATIONS. Other abstraction variations exist but have not been studied or categorized at this time. As one example, if an SQL injection vulnerability affects multiple executables in the same product, OSVDB will create one record for each affected program, whereas CVE will combine them. TIMELINESS: 8) RVIs differ in how quickly they must release vulnerability information. While this used to vary significantly in the past, these days most public RVIs have very short timelines, from the hour of release to within a few days. Vulnerability information can be volatile in the early stages, so an RVI's requirements for timeliness directly affects its veracity and completeness. REALITY: 9) All RVIs deal with limited resources or time, which significantly affects completeness, especially with respect to veracity, or timeliness (which is strongly associated with the ability to achieve completeness). Abstraction might also be affected, although usually to a lesser degree, except in the case of large-scale disclosures. Conclusion ---------- In my opinion: You should not interpret any RVI's statistics without considering its editorial policy. For example, the US-CERT Cyber Security Bulletin Summary for 2005 uses statistics that include replication. (As a side note, a causal glance at the bulletin's contents makes it clear that it cannot be used to compare Windows to Linux as operating systems.) In addition, you should not compare statistics from different RVIs until (a) the RVIs are clear about their editorial policy and (b) the differences in editorial policy can be normalized. Example: based on my PRELIMINARY investigations of a few hours' work, OSVDB would have about 50% more records than CVE, even though it has the same underlying number of vulnerabilities and the same completeness policy for recent issues. Third, for the sake of more knowledgeable analysis, RVIs should consider developing and publishing their own editorial policies. (Note that based on CVE's experience, this can be difficult to do.) Consumers should be aware that some RVIs might not be open about their raw sources, veracity analysis, and/or completeness. Finally: while RVIs are not yet ready to provide usable, conclusive statistics, there is a solid chance that they will be able to do so in the near future. Then, the only problem will be whether the statistics are properly interpreted. But that is beyond the scope of this letter. Steve Christey CVE Editor P.S. This post was written for the purpose of timely technical exchange. Members of the press are politely requested to consult me before directly attributing quotes from this article, especially with respect to stated opinion. From jericho at attrition.org Thu Jan 5 03:26:36 2006 From: jericho at attrition.org (security curmudgeon) Date: Thu, 5 Jan 2006 03:26:36 -0500 (EST) Subject: [VIM] amusing Linux Kernel changelog message Message-ID: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.15 commit 8f493d797bc1fe470377adc9d8775845427e240e Author: Andi Kleen Date: Tue Jan 3 00:07:28 2006 +0100 [PATCH] Make sure interleave masks have at least one node set Otherwise a bad mem policy system call can confuse the interleaving code into referencing undefined nodes. Originally reported by Doug Chapman I was told it's CVE-2005-3358 (one has to love these security people - they make everything sound important) From coley at linus.mitre.org Thu Jan 5 03:29:56 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Thu, 5 Jan 2006 03:29:56 -0500 (EST) Subject: [VIM] amusing Linux Kernel changelog message In-Reply-To: References: Message-ID: Regardless of the amusing nature, this is something that the Linux distros have wanted for a while. It's difficult to keep track of kernel vulns, and CVEs can help them with that. It's good to see it slowly making its way into kernel changelogs. On Thu, 5 Jan 2006, security curmudgeon wrote: > > http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.15 > > commit 8f493d797bc1fe470377adc9d8775845427e240e > Author: Andi Kleen > Date: Tue Jan 3 00:07:28 2006 +0100 > > [PATCH] Make sure interleave masks have at least one node set > > Otherwise a bad mem policy system call can confuse the interleaving > code into referencing undefined nodes. > > Originally reported by Doug Chapman > > I was told it's CVE-2005-3358 > (one has to love these security people - they make everything sound > important) > From jericho at attrition.org Thu Jan 5 03:32:38 2006 From: jericho at attrition.org (security curmudgeon) Date: Thu, 5 Jan 2006 03:32:38 -0500 (EST) Subject: [VIM] amusing Linux Kernel changelog message In-Reply-To: References: Message-ID: : Regardless of the amusing nature, this is something that the Linux : distros have wanted for a while. It's difficult to keep track of kernel : vulns, and CVEs can help them with that. It's good to see it slowly : making its way into kernel changelogs. I'd give my left arm to have it mandated that the Linux Kernel team had to work with CVE. Their changelogs are so huge, and the notations often hint at a potential vulnerability, but you just don't know until one of the kernel hackers or a researcher with time can figure it out. From jericho at attrition.org Thu Jan 5 06:00:01 2006 From: jericho at attrition.org (security curmudgeon) Date: Thu, 5 Jan 2006 06:00:01 -0500 (EST) Subject: [VIM] Vendor ACK: 21370: CS-Cart index.php Multiple Variable SQL Injection (fwd) Message-ID: ---------- Forwarded message ---------- From: Vladimir V. Kalynyak Date: Thu, 5 Jan 2006 13:57:36 +0300 Subject: [OSVDB Mods] [Change Request] 21370: CS-Cart index.php Multiple Variable SQL Injection Hello, My name is Vladimir Kalynyak, I'm a Senior Sales Executive at CS-Cart.com. Could you please a note to the listing 21370 that the issue with SQL injection has been fixed since CS-Cart version 1.3.0. Thank you Vladimir http://www.cs-cart.com/ From jericho at attrition.org Thu Jan 5 06:18:24 2006 From: jericho at attrition.org (security curmudgeon) Date: Thu, 5 Jan 2006 06:18:24 -0500 (EST) Subject: [VIM] EV0013 Question (fwd) Message-ID: Followup information to OSVDB 22198 / Secunia 18292 ---------- Forwarded message ---------- From: Support - eVuln.com Date: Thu, 05 Jan 2006 05:03:45 +0300 Subject: Re: EV0013 Question index.php only function "record_hit()" which calls from index.php only > http://evuln.com/vulns/13/exploit.html > > GET /path/index.php HTTP/1.0 > > > Does this work on any script, or just index.php? > From coley at linus.mitre.org Fri Jan 6 00:26:33 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 6 Jan 2006 00:26:33 -0500 (EST) Subject: [VIM] Vendor ACK: 21370: CS-Cart index.php Multiple Variable SQL Injection (fwd) In-Reply-To: References: Message-ID: Thanks... Added this VIM post as a reference to CVE-2005-4429, as prompted by Brian's inclusion of a VIM reference a few days ago. (lemming me is). Maybe we should announce it somewhere or at least start treating it as something that is public. What do y'all think? - Steve On Thu, 5 Jan 2006, security curmudgeon wrote: > > > ---------- Forwarded message ---------- > From: Vladimir V. Kalynyak > Date: Thu, 5 Jan 2006 13:57:36 +0300 > Subject: [OSVDB Mods] [Change Request] 21370: CS-Cart index.php Multiple > Variable SQL Injection > > Hello, > > My name is Vladimir Kalynyak, > > I'm a Senior Sales Executive at CS-Cart.com. > > Could you please a note to the listing 21370 that the issue with SQL > injection has been fixed since CS-Cart version 1.3.0. > > Thank you > Vladimir > http://www.cs-cart.com/ > From coley at mitre.org Fri Jan 6 00:54:23 2006 From: coley at mitre.org (Steven M. Christey) Date: Fri, 6 Jan 2006 00:54:23 -0500 (EST) Subject: [VIM] Add milw0rm to your watch lists Message-ID: <200601060554.k065sNrB025763@cairo.mitre.org> Not 100% sure, but looks like milw0rm is the a unique raw source for a handful of issues that are not published to other raw sources. http://milw0rm.com/ From jericho at attrition.org Fri Jan 6 05:24:10 2006 From: jericho at attrition.org (security curmudgeon) Date: Fri, 6 Jan 2006 05:24:10 -0500 (EST) Subject: [VIM] Xpdf/kpdf mess Message-ID: http://www.kde.org/info/security/advisory-20051207-1.txt CAN-2005-3191 CAN-2005-3192 CAN-2005-3193 Multiple overflows, seemed easy enough. http://www.kde.org/info/security/advisory-20051207-2.txt CAN-2005-3191 CAN-2005-3192 CAN-2005-3193 CVE-2005-3624 CVE-2005-3625 CVE-2005-3626 CVE-2005-3627 CESA-2005-003 Now, four more issues. CVE is closed currently, but even if they open i'm wondering how big of a mess this is. The original makes it sound like 'multiple overflows in xpdf', and kpdf shares a lot of the code. However, checking the gentoo bugzilla, we see this may affect a lot more applications. http://bugs.gentoo.org/show_bug.cgi?id=117481 Opening separate bugs for cups, poppler, gpdf. Handling pdftohtml, tetex, pdff, kword on their respective bugs that are still open. kpdf and kword already silently patched in CVS. So we have: cups, poppler, gpdf, pdftohtml, tetex, pdff, kword, kpdf This makes it sound like an underlying library, or each utility shared the vulnerable code? From jericho at attrition.org Fri Jan 6 07:42:43 2006 From: jericho at attrition.org (security curmudgeon) Date: Fri, 6 Jan 2006 07:42:43 -0500 (EST) Subject: [VIM] EV0014 question (fwd) Message-ID: ---------- Forwarded message ---------- From: Support - eVuln.com Date: Fri, 06 Jan 2006 17:17:15 +0300 Subject: Re: EV0014 question > 1. Arbitrary script execution. Example: > [a]javascript:alert("hello")[/a] > > > What script, fields or variables are affected by this? > > Arbitrary script execution is possible when posting a link in the messages like this: [a]http://host.com/[/a] Script: action.php Variable: $txt Script dont check $url for valid url. javascript code insertion is possible: [a]javascript:alert("hello")[/a] if somebody will click this link javascript will be executed. > 3. Directory Traversal Example: > Registering new user. > username: http://host/tpf/profile.php? action=view&uname=../../username > > > So during registration, you can traverse to a different username.. but > what does this do exactly? Overwrite an existing username with new data? > Sorry. There is a small mistake. http://host/tpf/profile.php?action=view&uname=../../username this link show users profile. so this vulnerability allays to view files with some extentions. Directory traversal is possible registration form too. It allows to create files(with some extentions) on server (write access is needed) > > Brian > OSVDB.org > > > From coley at linus.mitre.org Fri Jan 6 11:50:13 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 6 Jan 2006 11:50:13 -0500 (EST) Subject: [VIM] Xpdf/kpdf mess In-Reply-To: References: Message-ID: Even I don't have the details yet, although the later CANs all came from the same numbering authority, so they are likely distinct at least according to CVE's content decisions. I'll have to see. On Fri, 6 Jan 2006, security curmudgeon wrote: > > http://www.kde.org/info/security/advisory-20051207-1.txt > CAN-2005-3191 > CAN-2005-3192 > CAN-2005-3193 > > Multiple overflows, seemed easy enough. > > http://www.kde.org/info/security/advisory-20051207-2.txt > CAN-2005-3191 > CAN-2005-3192 > CAN-2005-3193 > CVE-2005-3624 > CVE-2005-3625 > CVE-2005-3626 > CVE-2005-3627 > CESA-2005-003 > > Now, four more issues. CVE is closed currently, but even if they open i'm > wondering how big of a mess this is. The original makes it sound like > 'multiple overflows in xpdf', and kpdf shares a lot of the code. However, > checking the gentoo bugzilla, we see this may affect a lot more > applications. > > http://bugs.gentoo.org/show_bug.cgi?id=117481 > > Opening separate bugs for cups, poppler, gpdf. > > Handling pdftohtml, tetex, pdff, kword on their respective bugs that are > still open. > > kpdf and kword already silently patched in CVS. > > > So we have: cups, poppler, gpdf, pdftohtml, tetex, pdff, kword, kpdf > > This makes it sound like an underlying library, or each utility shared the > vulnerable code? > From coley at linus.mitre.org Fri Jan 6 12:02:55 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 6 Jan 2006 12:02:55 -0500 (EST) Subject: [VIM] Xpdf/kpdf mess In-Reply-To: References: Message-ID: inquiry sent to Red Hat, Gentoo, and Chris Evans, who seems like the researcher. From coley at linus.mitre.org Fri Jan 6 12:05:42 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 6 Jan 2006 12:05:42 -0500 (EST) Subject: [VIM] Xpdf/kpdf mess In-Reply-To: References: Message-ID: On Fri, 6 Jan 2006, security curmudgeon wrote: > So we have: cups, poppler, gpdf, pdftohtml, tetex, pdff, kword, kpdf > > This makes it sound like an underlying library, or each utility shared the > vulnerable code? One or the other, probably. Based on the xpdf issues of a couple month ago, it appears that xpdf is used heavily in other libraries. CVE-2005-3191 through CVE-2005-3193 each have multiple references for different packages, including CUPS, poppler, pdftohtml, tetex, kword, kpdf. - Steve From coley at linus.mitre.org Fri Jan 6 12:48:46 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 6 Jan 2006 12:48:46 -0500 (EST) Subject: [VIM] xpdf/etc. - clarity needed for CVEs (fwd) Message-ID: FYI, I haven't updated the CVEs yet but this is important/timely enough I figured I'd pass it on. - Steve ---------- Forwarded message ---------- Date: Fri, 06 Jan 2006 12:38:42 -0500 From: [Red Hat] To: Chris Evans Cc: Steven M. Christey , [RED HAT], [GENTOO] Subject: Re: xpdf/etc. - clarity needed for CVEs Here are the bits you should need to update the entries: These numbers refer to Chris' advisory: http://scary.beasts.org/security/CESA-2005-003.txt 1) Out-of-bounds heap accesses with large or negative parameters to "FlateDecode" stream. * CVE-2005-3192 <- This overlaps with one of the iDEFENSE advisories 2) Out-of-bounds heap accesses with large or negative parameters to "CCITTFaxDecode" stream. * CVE-2005-3624 3) Infinite CPU spins in various places when stream ends unexpectedly. Probably repeated at various locations in the code. * CVE-2005-3625 4) NULL pointer crash in the "FlateDecode" stream. (This flaw happens to be fixed by the patch for CVE-2005-3192) * CVE-2005-3626 5) Overflows of compInfo array in "DCTDecode" stream. 6) Possible to use index past end of array in "DCTDecode" stream. 7) More possible out-of-bounds indexing trouble in "DCTDecode" stream. * CVE-2005-3627 Additionally, CVE-2005-3628 also refers to a buffer overflow in JBIG2Bitmap::JBIG2Bitmap() of JBIG2Stream.cc This was discovered by Ludwig Nussel and was silently fixed in most *pdf updates. From coley at mitre.org Fri Jan 6 19:13:32 2006 From: coley at mitre.org (Steven M. Christey) Date: Fri, 6 Jan 2006 19:13:32 -0500 (EST) Subject: [VIM] The provenance problem - one example Message-ID: <200601070013.k070DWgp013191@cairo.mitre.org> I've been thinking of the "provenance problem" as having multiple aspects: - the raw sources of vulnerability information are numerous and scattered; there is no longer a single source through which 90% of issues are published - with the emergence of competitive Refined Vulnerability Information (RVI) sources, there is often a dis-incentive to link to other sources, and there may be multiple reasons for not linking to the original advisory - researchers sometimes only send information directly to the RVI, instead of public channels - RVIs perform additional analysis, but the nature and quality of this analysis is usually hidden With the provenance problem, there's more work for RVI sources and more dependence on the accuracy of other RVIs when they are the sole source. Case in point... - SECUNIA:18324 / BID:16159 reported an SQL injection in Timecan CMS via the viewID parameter. Credit: Preddy - FRSIRT:ADV-2006-0078, on the same day, reported an SQL injection in Timecan CMS with the email parameter to mcl_login.asp. Credit: Preddy. So, is this the same vuln or not? Date of disclosure and researcher is the same. Attack details appear to be different. Maybe one RVI source did some deeper analysis, maybe not. As an outsider you can't tell without repeating the analysis on the product yourself. Oh, by the way - a quick glance suggests that Timecan might be an application service. - Steve PS. I need another term besides "RVI source" From jericho at attrition.org Sat Jan 7 07:23:01 2006 From: jericho at attrition.org (security curmudgeon) Date: Sat, 7 Jan 2006 07:23:01 -0500 (EST) Subject: [VIM] standards for inclusion of DoS attacks Message-ID: Does anyone have any thoughts, debates or even policy on what consitutes a 'DoS attack', in the context for inclusion into a VDB? I ask for a specific reason that comes up every month or so. What prompted this one: http://www-1.ibm.com/support/docview.wss?uid=swg27007054 This is a gnarly changelog of sorts. There are clearly security issues in here that will appear in every database. Secunia breaks out 7 entries in SA18328. My once through says OSVDB may have ~ 10 based on their 7. My second pass lead to this post. If you read through this changelog, you begin to see countless "crashes" and "memory leaks". Many of them suggest that an unprivileged user could manipulate the error to force the crash, some don't give any hint as to the privileges required to abuse it. I see both sides of the debate to include every single one. First, it is a legitimate attack against a system, with the potential to disrupt the service or user activity, without authorization. No matter how trivial, a clever attacker could use it. If you look at the entries most of us maintain for Linux Kernel DoS issues, a lot of them are akin to these. They take a fairly specific configuration or kernel compilation, local access to the machine (usually), and a knowledgable attacker. As such, they get entries in the VDB. Yet in the past, we have all glossed over these changelogs, typically from the big vendors like IBM, HP or Sun. That leads into the other side of the argument. Second, the computer industry is not at a stage where we have stable software for the most part. Programs are still horrible at sanitizing user input. While they are getting better at sanitizing *some* input, it is specific to known attack vectors like overflows, format strings, sql injections and more. Most are bad about filtering "all other junk someone may throw at this", which leads to these typs of changelogs. If a VDB is expected to make an entry for every way to crash a server or application, we could potentially expect to see several thousand more entries every year (scaling up as each year goes by). As such, it isn't prudent to add each and every one at this point. If you subscribe to #1 and haven't done it for your database, i'd guess it is a time/resource issue. It can take hours to sort through that changelog and think about which get an entry, then hours more to create them in the database. If that is the case, I fully understand it and it is the exact reason I have skipped over some of these changelogs in the past. If you subscribe to #2, what is the fine line that dictates which get an entry and which doesn't? I am not dead set on every single DoS attack getting an entry, but I find myself having a hard time deciding where the line is. Solely based on access/privileges required? Based on how feasible an attack is using the method? Something else? Brian ps: this is on my to-blog about list. From mattmurphy at kc.rr.com Sat Jan 7 16:53:26 2006 From: mattmurphy at kc.rr.com (Matthew Murphy) Date: Sat, 07 Jan 2006 15:53:26 -0600 Subject: [VIM] standards for inclusion of DoS attacks In-Reply-To: References: Message-ID: <43C03856.2060105@kc.rr.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Brian, On servers, gateways, etc. (multi-user infrastructure of any kind, really), the "Apache standard" is a good starting point. - From the Apache Software Foundation's "Security Reports" page (http://httpd.apache.org/security_report.html): "Note that all networked servers are subject to denial of service attacks, and we cannot promise magic workarounds to generic problems (such as a client streaming lots of data to your server, or re-requesting the same URL repeatedly). In general our philosophy is to avoid any attacks which can cause the server to consume resources in a non-linear relationship to the size of inputs." In general, I would treat memory leaks, crashes, or non-linear resource uses as listable issues. This seems to be a relative standard. The more interesting issues are client-side. Most people don't treat the ability to cause a memory leak or a crash in a client-side app as a serious security issue. That's because there's no repeat factor in a client app. The client has to return to whatever resource crashed it previously. Exceptions to this include so-called persistent attacks, where a single viewing of a malicious resource renders the client application unusable for a lengthy time period. Also up in the air is an attack against a semi-passive client. Let's use Instant Messaging as an example. It's unclear if it would be considered a vulnerability for me to be able to crash client-side applications by actually sending their users data. In that case, the active party is the attacker, not the victim. So, in summary: * Crash, reproducible memory leak, or non-linear resource consumption is a prerequisite of a DoS being a security issue. On servers, this appears to be the standard for what is a security issue. * Persistent, continual effects of the attack probably indicate a security issue. * If there's a means for the attacker to initiate the attack, it might be a security issue. Instant Messengers, for instance, would be an example. More up in the air are things like e-mail. In those cases, the client would still have to download a message, so the attack isn't fully automatic from a delivery point-of-view. The standard disclaimer applies (this is really my opinion and based on my limited personal experience, use it at your own risk, etc.), but I hope that it helps. - -- "Social Darwinism: Try to make something idiot-proof, nature will provide you with a better idiot." -- Michael Holstein -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDwDhWfp4vUrVETTgRA+4EAJ0UyqxSFhjMAKd8vs3AXYesdbtoRACfeqMJ tsW20kqPwhXHcOCuSHcroRg= =bpfr -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3436 bytes Desc: S/MIME Cryptographic Signature Url : http://www.attrition.org/pipermail/vim/attachments/20060107/f954924a/attachment.bin From coley at linus.mitre.org Mon Jan 9 00:24:18 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Mon, 9 Jan 2006 00:24:18 -0500 (EST) Subject: [VIM] standards for inclusion of DoS attacks In-Reply-To: References: Message-ID: The Editorial Board had some discussion on this a number of years ago, encoded roughly in the "EX-CLIENT-DOS" content decision. It said roughly "exclude DoS on a client unless it is persistent." One problem with this was that potential buffer overflows could be excluded based on symptoms only (does a recent IE bug ring a bell?). Plus a fairly large number of VDB's include them, so CVE's role as communications facilitator sort of led us to start including most DoS. DoSes in other product classes were not really discussed. generally I'm of the mindset that a "normal" user shouldn't be allowed to (1) do something that impacts other users (e.g. halt someone else's processes by causing a kernel crash) (2) slow down the system or otherwise consume more resources beyond that which is "reasonable" - a bit fuzzy here, but asymmetric algorithmic complexity attacks come to mind, log filling etc. (3) "hog" or control a set of resources that is intended for another party and/or to be shared by multiple parties (4) conduct any sort of persistent DoS that is not immediately recoverable by the typical user Memory leaks - if attacker-controllable (which most probably are) - fall under legitimate DoS for me. If in 5 or 10 years all operating systems with widely-implemented, well-managed process memory restrictions then maybe that will be different. Reading things from changelogs is difficult, specifically because the role of an attacker is rarely specified. In these cases, if some other VDB notes it, I'll probably add a note in the CVE description - at the very least mentioning unknown attack vectors, and probably saying "this might not be a vuln." At some point the line between security and reliability gets very fuzzy, and it varies for different customers. This is ESPECIALLY the case for crashes due to un-analyzed malformed inputs. "I piped /dev/random through netcat to product X and all I got was this lousy crash" issues are almost always undiagnosed and *might* be some more serious issue underneath - remember when heap overflows weren't exploitable, or when people manipulated array indexes without sufficiently realizing they could modify arbitrary memory? So given the immaturity of analysis, it seems safest to include most DoS unless (a) the impact is restricted entirely to the attacker and/or (b) recoverable without any loss by the victim. So if you have a multi-threaded server and an attack causes a crash in the attacker's own thread but the thread is automatically restarted, that's not really a DoS to me. - Steve From coley at linus.mitre.org Mon Jan 9 00:32:02 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Mon, 9 Jan 2006 00:32:02 -0500 (EST) Subject: [VIM] standards for inclusion of DoS attacks In-Reply-To: <43C03856.2060105@kc.rr.com> References: <43C03856.2060105@kc.rr.com> Message-ID: Oh, I forgot to mention one of my favorite little phrases. I do not include "laws-of-physics" vulnerabilities in which the laws of physics would have to be broken to protect against them. e.g. if I send OC3 traffic to a 28.8 modem, then I should expect a noticeable slowdown. - Steve From coley at mitre.org Mon Jan 9 12:33:55 2006 From: coley at mitre.org (Steven M. Christey) Date: Mon, 9 Jan 2006 12:33:55 -0500 (EST) Subject: [VIM] older MegaBBS issue not picked up by VDBs Message-ID: <200601091733.k09HXte5011533@cairo.mitre.org> FYI - this was in the same big vendor forum page as the recently disclosed send-private-message issue. ====================================================== Name: CVE-2004-2653 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2653 Reference: CONFIRM:http://www.pd9soft.com/megabbs/forums/thread-view.asp?tid=4924 Unspecified vulnerability in PD9 Software MegaBBS 2.0 and 2.1 allows attackers to gain privileges via unknown vectors involving (1) admin/userlevelmembers-edit.asp and (2) admin/edit-groups.asp. From jericho at attrition.org Wed Jan 11 04:01:32 2006 From: jericho at attrition.org (security curmudgeon) Date: Wed, 11 Jan 2006 04:01:32 -0500 (EST) Subject: [VIM] vendor ack: 21240: eazyCMS home.php page_id Variable SQL Injection (fwd) Message-ID: ---------- Forwarded message ---------- From: Toby Maxwell-Lyte To: moderators at osvdb.org Date: Wed, 11 Jan 2006 08:54:32 +0000 Subject: [OSVDB Mods] [Change Request] 21240: eazyCMS home.php page_id Variable SQL Injection Hi, This vulnerabilty has now been fixed. Kind regards, Toby -- Toby Maxwell-Lyte Project Manager From jericho at attrition.org Wed Jan 11 04:34:34 2006 From: jericho at attrition.org (security curmudgeon) Date: Wed, 11 Jan 2006 04:34:34 -0500 (EST) Subject: [VIM] site specific, not product: 21240: eazyCMS Message-ID: ---------- Forwarded message ---------- From: Toby Maxwell-Lyte To: security curmudgeon Date: Wed, 11 Jan 2006 09:29:42 +0000 Subject: Re: [OSVDB Mods] [Change Request] 21240: eazyCMS home.php page_id Variable SQL Injection yes, this is correct. eazyCMS is fully hosted solution. When our clients purchase a website from us we supply them with eazyCMS so that they can update the content of their website that we are hosting for them. This is why I was slightly puzzled to see vulnerability reports appearing on the web about our product. Kind regards, Toby security curmudgeon wrote: > : We have fixed this bug via an upgrade. All our clients run off the same : > system and thus benefit immediately from any updates, patches or fixes : that > we perform. As we also host the system we have full control over : ensuring > that it is secure for all our clients. > > Wait.. so eazyCMS is not a downloadable product, but a service your company > offers? > > Brian > OSVDB.org From coley at mitre.org Wed Jan 11 21:37:26 2006 From: coley at mitre.org (Steven M. Christey) Date: Wed, 11 Jan 2006 21:37:26 -0500 (EST) Subject: [VIM] Verified ACal issue(s) Message-ID: <200601120237.k0C2bQEY027329@cairo.mitre.org> I verified (source inspection) the ACal issues reported by alex at evuln. Based on my read, the header.php/footer.php modification is RESULTANT from the poor authentication issue. The edit.php file clearly intends to allow the admin to replace header.php and footer.php in their entirety if need be, but it's only the poor authentication that lets it occur. My current thinking is that I'd argue that only the primary issue - i.e. poor authentication - should be included, with PHP execution as a consequence. Although PHP hosting solution providers might care about even letting ACal admins modify their own header/footer code. - Steve ====================================================== Name: CVE-2006-0182 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0182 Reference: MISC:http://evuln.com/vulns/25/summary.html Reference: FRSIRT:ADV-2006-0152 Reference: URL:http://www.frsirt.com/english/advisories/2006/0152 login.php in ACal Calendar Project 2.2.5 allows remote attackers to bypass authentication by setting the ACalAuthenticate cookie variable to "inside". ====================================================== Name: CVE-2006-0183 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0183 Reference: MISC:http://evuln.com/vulns/25/summary.html Reference: FRSIRT:ADV-2006-0152 Reference: URL:http://www.frsirt.com/english/advisories/2006/0152 Direct static code injection vulnerability in edit.php in ACal Calendar Project 2.2.5 allows authenticated users to execute arbitrary PHP code via (1) the edit=header value, which modifies header.php, or (2) the edit=footer value, which modifies footer.php. NOTE: this issue might be resultant from the poor authentication as identified by CVE-2006-0182. Since the design of the product allows the administrator to edit the code, perhaps this issue should not be included in CVE, except as a consequence of CVE-2006-0182. From coley at mitre.org Thu Jan 12 01:32:34 2006 From: coley at mitre.org (Steven M. Christey) Date: Thu, 12 Jan 2006 01:32:34 -0500 (EST) Subject: [VIM] Antharia OnContent // CMS might be an app provider Message-ID: <200601120632.k0C6WYUT000585@cairo.mitre.org> FYI a look at the Antharia web site suggests that they're an application service provider or whatever you want to call it these days. This trend is gonna make for some headaches and more time, but I'm not sure we can keep them out of VDBs forever. At the moment I'm thinking of a content decision "... only include an app provider if customers have the option to download and maintain the apps themselves" but I'm still creating candidates for tracking purposes. Things like Google and Yahoo are easy to omit... but this highlights a gap in the VDB community, as it might be nice if someone somewhere tracked this stuff even though it's universally fixed almost as soon as it's reported. - Steve From coley at mitre.org Fri Jan 13 01:31:29 2006 From: coley at mitre.org (Steven M. Christey) Date: Fri, 13 Jan 2006 01:31:29 -0500 (EST) Subject: [VIM] BEA03-43.00 mess Message-ID: <200601130631.k0D6VTPo019418@cairo.mitre.org> BEA's advisory web archives are causing trouble again (yes Brian, I remember your rant). BEA03-43.00 was apparently just added to their "new" site layout (the one without forwarding URLs from the old URLs): http://dev2dev.bea.com/advisoriesnotifications/ Search for "BEA03-43.00" and there you go - this was published 2003-11-11. WHY did it suddenly show up in several VDBs with a "published" date of 2006-01-12? WELLLLLLL... here are two reasons: 1) this OLD advisory has the URL: http://dev2dev.bea.com/pub/advisory/162 but the MOST RECENT advisory had the URL: http://dev2dev.bea.com/pub/advisory/161 So, if some VDB's watch list is dynamic enough to look for the most recently added advisory based on increasing numbers, suddenly this will pop up. 2) THE ADVISORY DOES NOT HAVE ANY DATE FIELD ASSOCIATED WITH IT! Of course, the "03" in "BEA03-43.00" is a mini-clue that something's awry, but whatever. Insert jericho rant here, and check your published dates (after you've checked for dupes, of course.) - Steve From jericho at attrition.org Fri Jan 13 03:22:21 2006 From: jericho at attrition.org (security curmudgeon) Date: Fri, 13 Jan 2006 03:22:21 -0500 (EST) Subject: [VIM] vendor ack/fix: 21914 Adaptive Website Framework (fwd) Message-ID: ---------- Forwarded message ---------- From: Michael Mayer Date: Fri, 13 Jan 2006 09:17:57 +0100 Subject: [OSVDB Mods] [Change Request] 21914 Adaptive Website Framework Hi there, the described XSS bug was fixed some days ago. We didn't get informed about this bug, so I had to find out using google ;) See http://www.awf-cms.org/news.html http://pridels.blogspot.com/2005/12/awf-adaptive-website-framework-vuln.html Greetings, -- Michael Mayer Liquid Bytes Technologies www.LiquidBytes.net From coley at linus.mitre.org Fri Jan 13 03:26:26 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 13 Jan 2006 03:26:26 -0500 (EST) Subject: [VIM] vendor ack/fix: 21914 Adaptive Website Framework (fwd) In-Reply-To: References: Message-ID: score yet another one for r0t! the methods might be minimal but they're effective. From jericho at attrition.org Fri Jan 13 08:14:09 2006 From: jericho at attrition.org (security curmudgeon) Date: Fri, 13 Jan 2006 08:14:09 -0500 (EST) Subject: [VIM] vendor dispute: 21565: phpBB Blog index.php permalink Variable SQL Injection (fwd) Message-ID: I have mailed asking he test something else. ---------- Forwarded message ---------- From: Tony Boyd To: moderators at osvdb.org Date: Fri, 13 Jan 2006 04:58:16 -0800 Subject: [OSVDB Mods] [Change Request] 21565: phpBB Blog index.php permalink Variable SQL Injection I believe your notice about SQL injection into phpBB Blog is incorrect. As the author, I saw the advisory, and attempted to do as shown (append SQL to the URL string). The SQL was not executed. In addition, the advisory suggests that the script is not properly sanitizing user-supplied input to the "permalink" variable. However, it is. This line in blog.php sanitizes the data: $perma_id = preg_replace("/[^0-9]/", "", $_GET['permalink']); -Tony From jericho at attrition.org Fri Jan 13 08:33:13 2006 From: jericho at attrition.org (security curmudgeon) Date: Fri, 13 Jan 2006 08:33:13 -0500 (EST) Subject: [VIM] [OSVDB Mods] [Change Request] 21565: phpBB Blog index.php permalink Variable SQL Injection (fwd) Message-ID: ---------- Forwarded message ---------- From: Tony Boyd To: security curmudgeon Cc: moderators at osvdb.org Date: Fri, 13 Jan 2006 05:32:09 -0800 Subject: Re: [OSVDB Mods] [Change Request] 21565: phpBB Blog index.php permalink Variable SQL Injection Brian, No errors. See here: http://www.outshine.com/phpbbblog/demo/?permalink=302' http://www.outshine.com/phpbbblog/demo/?permalink=302';SHOW TABLES: http://www.outshine.com/phpbbblog/demo/?permalink=302';'SELECT * FROM foo' Since my program strips everything except numbers, only "302" appears in the SQL query. -Tony security curmudgeon wrote: > Hi Tony, > > : I believe your notice about SQL injection into phpBB Blog is incorrect. > : : As the author, I saw the advisory, and attempted to do as shown (append : > SQL to the URL string). The SQL was not executed. > : : In addition, the advisory suggests that the script is not properly : > sanitizing user-supplied input to the "permalink" variable. However, it : > is. This line in blog.php sanitizes the data: > : : $perma_id = preg_replace("/[^0-9]/", "", $_GET['permalink']); > > Can you try supplying a single quote character (') to the variable, and see > if throws an SQL error? The person who originally found this is well known > for only performing that test before claiming "sql injection". If it does > throw an SQL error, that is what prompted his assumption, even if the > variable is sanitized. 9 times out of 10, seeing an SQL error in such a case > *is* an indication of injection possibility. However, 1 out of 10 it's a > false positive =) > > Brian > OSVDB.org > > > From jericho at attrition.org Fri Jan 13 08:37:04 2006 From: jericho at attrition.org (security curmudgeon) Date: Fri, 13 Jan 2006 08:37:04 -0500 (EST) Subject: [VIM] [OSVDB Mods] [Change Request] 21565: phpBB Blog index.php permalink Variable SQL Injection (fwd) Message-ID: ---------- Forwarded message ---------- From: security curmudgeon To: Tony Boyd Cc: moderators at osvdb.org Date: Fri, 13 Jan 2006 08:36:52 -0500 (EST) Subject: Re: [OSVDB Mods] [Change Request] 21565: phpBB Blog index.php permalink Variable SQL Injection Hey Tony, : No errors. See here: : : http://www.outshine.com/phpbbblog/demo/?permalink=302' If I try: http://www.outshine.com/phpbbblog/demo/?permalink It gives me the following error: General Error Querying the database didn't work. Feeling helpful? Email the webmaster. DEBUG MODE SQL Error : 1064 You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near 'AND topic_type=0 ORDER BY topic_time DESC LIMIT 1' at line 1 Notice the SQL error? While it didn't take a ' to cause it, that is no doubt what the original discoverer saw that prompted them to make this claim. So it appears that no input will cause the SQL error, but if you actually try to pass any special characters, they are sanitized, as your examples above show. Would you agree? Brian OSVDB.org From coley at linus.mitre.org Fri Jan 13 13:42:09 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 13 Jan 2006 13:42:09 -0500 (EST) Subject: [VIM] vendor dispute: 21565: phpBB Blog index.php permalink Variable SQL Injection (fwd) In-Reply-To: References: Message-ID: This is a typical invalid SQL syntax issue. I might have to start flagging all r0t advisories as potentially erroneous. I'll forward my email to him. - Steve From coley at linus.mitre.org Fri Jan 13 13:43:47 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 13 Jan 2006 13:43:47 -0500 (EST) Subject: [VIM] security exploit - false positive (fwd) Message-ID: Here you go. I should REALLY write up some testing / clarification notes to automatically send to vendors. ---------- Forwarded message ---------- Date: Fri, 13 Jan 2006 13:38:54 -0500 (EST) From: Steven M. Christey To: 'Tony Boyd' Cc: cve at mitre.org, 'Steven M. Christey' Subject: RE: security exploit - false positive Tony, I have noticed a positive trend of clarifications coming from vendors, and I appreciate it. I was wondering how you were made aware of this issue? (We would love to notify all vendors but as you will see in this followup, it is extremely resource-intensive and beyond CVE's scope to do for everything.) This issue was found by a somewhat reliable researcher, in that when he reports something, there's usually something real going on. However, he also mis-diagnoses many SQL errors as if they are SQL injection, and this might be what happened here. I've publicly warned researchers about this mistake in the past, but they still make it. Here's my bet: - he entered a ' (single quote) - your preg_replace made $permalink be "" - with PHP errors on, this generated a SQL error because the argument is non-numeric (and blank): SELECT topic_id FROM [whatever]topics WHERE forum_id = $forum AND topic_id< See? no numeric argument after topic_id. Invalid syntax, error generated. (Actually you seem to assume that $forum is also defined, which in r0t's example it's not) So, try this: - enable PHP display_errors "on" - provide permalink with a ' argument I'll rephrase the description to state that this is a path disclosure problem related to invalid SQL syntax, and I'll try to get r0t to understand that he needs to be better about diagnosis. I will forward your comments to other vuln DBs, as well as this answer. Regards, Steve Christey CVE Editor On Fri, 13 Jan 2006, Peter Mell wrote: > Tony, > > NVD is a search engine and database for the CVE vulnerability dictionary. > The CVE staff make the decision about what constitutes a vulnerability and > NVD synchronizes with, and adds to, their information. Thus, this issue will > need to be corrected within CVE and it will then be automatically updated > within NVD. > > I have included the CVE staff in this email so that they can assist you. > > Best wishes, > Peter Mell > NVD Project Lead > > > -----Original Message----- > > From: Tony Boyd > > Sent: Friday, January 13, 2006 8:02 AM > > To: nvd at nist.gov > > Subject: security exploit - false positive > > > > I believe your notice about SQL injection into phpBB Blog is incorrect. > > Your notice appears here: > > > > http://nvd.nist.gov/nvd.cfm?cvename=CVE-2005-4346 > > > > As the author, I saw the advisory, and attempted to do as shown (append > > SQL to the URL string). The SQL was not executed. > > > > In addition, the advisory suggests that the script is not properly > > sanitizing user-supplied input to the "permalink" variable. However, it > > is. This line in blog.php sanitizes the data: > > > > $perma_id = preg_replace("/[^0-9]/", "", $_GET['permalink']); > > > > -Tony > > > > > > From coley at linus.mitre.org Fri Jan 13 16:05:19 2006 From: coley at linus.mitre.org (Steven M. Christey) Date: Fri, 13 Jan 2006 16:05:19 -0500 (EST) Subject: [VIM] security exploit - false positive (fwd) Message-ID: vendor ACK for phpBB blog (CVE-2005-4346). Issue is actually in blog.php, as included by index.php. - Steve ---------- Forwarded message ---------- Date: Fri, 13 Jan 2006 12:47:22 -0800 From: Tony Boyd To: Steven M. Christey Subject: Re: security exploit - false positive Steve, [snip] I tried to reproduce the SQL injection, but could not. And since I strip out non-numeric characters, I couldn't conceive of how SQL code was getting in. I thought maybe my regex was leaky, but I couldn't find a way to get around it in my own testing. You are correct, when entering a single quote with nothing else, the single quote is stripped, leaving no number. This should cause an SQL error, because no id was specified. It doesn't mean SQL injection, though. From jericho at attrition.org Fri Jan 13 18:25:14 2006 From: jericho at attrition.org (security curmudgeon) Date: Fri, 13 Jan 2006 18:25:14 -0500 (EST) Subject: [VIM] "Google" vulnerable to WMF? Message-ID: http://www.kb.cert.org/vuls/id/181038 Systems Affected Vendor Status Date Updated Google Vulnerable 30-Dec-2005 IrfanView Vulnerable 4-Jan-2006 Lotus Software Unknown 4-Jan-2006 Microsoft Vulnerable 5-Jan-2006 Mozilla, Inc. Unknown 28-Dec-2005 XnView Vulnerable 4-Jan-2006 http://www.kb.cert.org/vuls/id/JSHA-6KHRA9 Google Information for VU#181038 Date Notified 12/28/2005 Date Modified 01/10/2006 02:14:05 PM Status Summary Vulnerable Vendor Statement No statement is currently available from the vendor regarding this vulnerability. US-CERT Addendum There are no additional comments at this time. If you have feedback, comments, or additional information about this vulnerability, please send us email. From coley at mitre.org Fri Jan 13 18:38:02 2006 From: coley at mitre.org (Steven M. Christey) Date: Fri, 13 Jan 2006 18:38:02 -0500 (EST) Subject: [VIM] Verified TankLogger SQl inject by source inspection Message-ID: <200601132338.k0DNc2H7003576@cairo.mitre.org> re: http://evuln.com/vulns/26/description.html (CVE forthcoming) By source inspection of TankLogger 2.4, I was able to verify the livestock_id vector and found something related to tank_id. ******** first: researcher mentions general_functions.php but this doesn't seem to be relevant, at least not to the vectors I examined. second: researcher mentions showInfo.php but it doesn't have tank_id in it at all. 1) getVar() in general_functions.php will perform an addslashes() on the value *only* if an optional second argument is true (default is false). 2) from showInfo.php: $livestock_id = getVar("livestock_id"); if ($livestock_id != "") { $livestock = new Livestock($mysql_object, $livestock_id); 3) So, $livestock_id does NOT have an addslashes. 4) Livestock.php has the following: function Livestock($mysql_object, $livestock_id) { $query = "SELECT livestock_id, purchased_from, common_name, scientific_name, date_added, tank_id, pet_name, vendor_id, DATE_FORMAT(date_added, '%M %D, %Y') AS ts FROM livestock WHERE livestock_id = '$livestock_id'"; 5) Therefore since there's no addslashes, the code in #2 allows SQL injection. ********** The researcher also mentions tank_id. There was no mention of it in general_functions.php or showInfo.php. However, livestock.php uses a tank_id that appears vulnerable to SQL injection in a manner similar to livestock_id, i.e.: - getVar without "true" second argument - creation of Tank object with attacker-controlled tank_id - Tank create method feeds tank_id directly into SQL query From mattmurphy at kc.rr.com Fri Jan 13 23:24:01 2006 From: mattmurphy at kc.rr.com (Matthew Murphy) Date: Fri, 13 Jan 2006 22:24:01 -0600 Subject: [VIM] "Google" vulnerable to WMF? In-Reply-To: References: Message-ID: <43C87CE1.9020001@kc.rr.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 security curmudgeon wrote: > > http://www.kb.cert.org/vuls/id/181038 > > Systems Affected > > Vendor Status Date Updated > > Google Vulnerable 30-Dec-2005 > IrfanView Vulnerable 4-Jan-2006 > Lotus Software Unknown 4-Jan-2006 > Microsoft Vulnerable 5-Jan-2006 > Mozilla, Inc. Unknown 28-Dec-2005 > XnView Vulnerable 4-Jan-2006 Google's "Desktop Search" products uses the susceptible component to "size down" images for display when returning search results. As a result of this sizing down, the WMF exploit may be executed. - -- "Social Darwinism: Try to make something idiot-proof, nature will provide you with a better idiot." -- Michael Holstein -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDyHzhfp4vUrVETTgRAwR6AJ9uc/qmntgmAmvCuTBW80ljGAVgZQCgm1R7 2j/x+TtpA02xKfekY0N6qzU= =5GxD -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3436 bytes Desc: S/MIME Cryptographic Signature Url : http://www.attrition.org/pipermail/vim/attachments/20060113/cc820dec/attachment.bin From jericho at attrition.org Sat Jan 14 17:23:42 2006 From: jericho at attrition.org (security curmudgeon) Date: Sat, 14 Jan 2006 17:23:42 -0500 (EST) Subject: [VIM] "Google" vulnerable to WMF? In-Reply-To: <43C87CE1.9020001@kc.rr.com> References: <43C87CE1.9020001@kc.rr.com> Message-ID: : > Google Vulnerable 30-Dec-2005 : : Google's "Desktop Search" products uses the susceptible component to : "size down" images for display when returning search results. As a : result of this sizing down, the WMF exploit may be executed. Doesn't Firefox and a dozen other programs too? I mean, they are all vectors of an attack, but the actual vulnerability and susceptible code is in Windows, right? Google software/code itself doesn't have the weakness? From jericho at attrition.org Sat Jan 14 18:19:55 2006 From: jericho at attrition.org (security curmudgeon) Date: Sat, 14 Jan 2006 18:19:55 -0500 (EST) Subject: [VIM] Antharia OnContent // CMS might be an app provider In-Reply-To: References: <200601120632.k0C6WYUT000585@cairo.mitre.org> Message-ID: : FYI a look at the Antharia web site suggests that they're an : application service provider or whatever you want to call it these : days. http://www.antharia.com/media/antharia-cms-070104.pdf No Monthly Fees Once we have installed and configured your CMS, there are no monthly user fees. We can set you up on your server or ours. -- This leads me to believe it can be a standalone product, not service.. but they would rather you set up shop on their boxes (and possibly get support contract money). From mattmurphy at kc.rr.com Sat Jan 14 22:54:25 2006 From: mattmurphy at kc.rr.com (Matthew Murphy) Date: Sat, 14 Jan 2006 21:54:25 -0600 Subject: [VIM] "Google" vulnerable to WMF? In-Reply-To: References: <43C87CE1.9020001@kc.rr.com> Message-ID: <43C9C771.5020900@kc.rr.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 security curmudgeon wrote: > : > Google Vulnerable 30-Dec-2005 > : > : Google's "Desktop Search" products uses the susceptible component to > : "size down" images for display when returning search results. As a > : result of this sizing down, the WMF exploit may be executed. > > Doesn't Firefox and a dozen other programs too? I mean, they are all > vectors of an attack, but the actual vulnerability and susceptible code is > in Windows, right? Google software/code itself doesn't have the > weakness? Not directly. Problem is, Google auto-indexes the exploit files, in essence "opening" the malicious file. That makes it uniquely bad from a user-interaction point-of-view. It's a lot like Lotus Notes is believed to be -- view a document and instantaneously you're infected. - -- "Social Darwinism: Try to make something idiot-proof, nature will provide you with a better idiot." -- Michael Holstein -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDycdxfp4vUrVETTgRA7xHAJ4u7LyzVk0eVh9o4LK2MVYWrVtJjgCcDNwu DKTPrL8I/RkyZtvivyQ805I= =25GR -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3436 bytes Desc: S/MIME Cryptographic Signature Url : http://www.attrition.org/pipermail/vim/attachments/20060114/5caff81b/attachment.bin From coley at mitre.org Sun Jan 15 01:57:03 2006 From: coley at mitre.org (Steven M. Christey) Date: Sun, 15 Jan 2006 01:57:03 -0500 (EST) Subject: [VIM] Vendor ACK for PHPWordPress Message-ID: <200601150657.k0F6v3tM000613@cairo.mitre.org> Re: CVE-2005-3844 CONFIRM: http://forum.word-press.net/index.php?&showtopic=76&st=0&#entry181 A critical vulnerability has been found in phpWordPress, which can be exploited by malicious people to conduct SQL injection attacks. The vulnerability allows attackers to manipulate input passed to the "poll", "category", and "ctg" parameters in "index.php". This can be exploited to manipulate SQL queries by injecting arbitrary SQL code. - Steve ====================================================== Name: CVE-2005-3844 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3844 Reference: MISC:http://pridels.blogspot.com/2005/11/phpwordpress-30-sql-inj.html Reference: FRSIRT:ADV-2005-2594 Reference: URL:http://www.frsirt.com/english/advisories/2005/2594 Reference: SECUNIA:17733 Reference: URL:http://secunia.com/advisories/17733 SQL injection vulnerability in phpWordPress PHP News and Article Manager 3.0 allows remote attackers to execute arbitrary SQL commands via the (1) poll and (2) category parameters to index.php, and (3) the ctg parameter in an archive action. From jericho at attrition.org Mon Jan 16 00:07:15 2006 From: jericho at attrition.org (security curmudgeon) Date: Mon, 16 Jan 2006 00:07:15 -0500 (EST) Subject: [VIM] vendor ack/fix: 22198: raSMP index.php User-Agent Field XSS (fwd) Message-ID: ---------- Forwarded message ---------- From: Adam Alkins To: moderators at osvdb.org Date: Mon, 16 Jan 2006 01:05:28 -0400 Subject: [OSVDB Mods] [Change Request] 22198: raSMP index.php User-Agent Field XSS This was fixed in version 2.0.1 From coley at mitre.org Mon Jan 16 13:34:20 2006 From: coley at mitre.org (Steven M. Christey) Date: Mon, 16 Jan 2006 13:34:20 -0500 (EST) Subject: [VIM] Source code VERIFY of Wordcircle SQL injection Message-ID: <200601161834.k0GIYK3k027023@cairo.mitre.org> Re: CVE-2006-0205 Re: http://evuln.com/vulns/27/summary.html Re: http://evuln.com/vulns/28/summary.html I verified the above SQL injection issue by source inspection. In Wordcircle 2.17, the login() method of the "user" class in s_user.php is this: > function login(){ > > $security_code = md5(uniqid(rand(), true)); > $result = $GLOBALS['db']->execQuery("select user_id,first_name,last_name,email from users where email = '" . strtolower(trim(urldecode($_POST['email']))) . "' and pword = '" . strtolower(trim(urldecode($_POST['password']))) . "'"); > if(mysql_num_rows($result) > 0){ in v_login we have this: > $url = $GLOBALS['user']->login(); and in index.php we have: >elseif ($_GET['a'] == 'login'){ > > include("v_login.php"); > >} - Steve From coley at mitre.org Tue Jan 17 00:26:02 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 17 Jan 2006 00:26:02 -0500 (EST) Subject: [VIM] Wrong disclosure dates on 21875, 21874 Message-ID: <200601170526.k0H5Q2U5006400@cairo.mitre.org> 21875 and 21874 have a disclosure year of 2004, but it's 2005. - Steve From jericho at attrition.org Tue Jan 17 07:31:10 2006 From: jericho at attrition.org (security curmudgeon) Date: Tue, 17 Jan 2006 07:31:10 -0500 (EST) Subject: [VIM] [OSVDB Mods] CubeCart 3.0.7-pl1 index.php multiple variable cross site scripting In-Reply-To: <2344e9590601161102x4f9cf2e1s@mail.gmail.com> References: <2344e9590601161102x4f9cf2e1s@mail.gmail.com> Message-ID: Hey Lostmon, : CubeCart 3.0.7-pl1 vulnerable. : Other versions are posible vulnerables too : Examples: http://osvdb.org/19861 This is interesting. The cart.php redir variable XSS was disclosed on 2005-09-28 and said to affect 3.0.3, with upgrading to 3.0.4 as a solution. It appears that version may not have really fixed it, or vulnerable code was reintroduced to the product. http://osvdb.org/19860 Same thing with index.php and the 'redir' and 'searchStr' variables. Reported to affect 3.0.3 and upgrading to 3.0.4 as the solution. With this report, it seems more variables in index.php are affected now, specifically: http://victim]/cc3/index.php?act=viewProd&productId=1"> http://victim]/cc3/index.php?act=viewDoc&docId=3"> http://victim]/cc3/index.php?act=viewProd"> http://victim]/cc3/index.php?act=viewCat&catId=1"> http://victim]/cc3/index.php?act=viewCat&catId=saleItems"> http://victim]/cc3/index.php?searchStr=%22%3E%3Cscript%3Ealert%28%29%3C%2Fscript%3E&act=viewCat http://victim]/cc3/index.php?act=viewDoc&docId=1"> Very interesting.. Brian From coley at mitre.org Tue Jan 17 13:29:48 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 17 Jan 2006 13:29:48 -0500 (EST) Subject: [VIM] More details on PHP XSS fix Message-ID: <200601171829.k0HITmtp016693@cairo.mitre.org> Re: CVE-2006-0208 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178028 This says: The problem exists in the way PHP displays error messages. This issue is only exploitable when 'display_errors' and 'html_errors' are both set to 'On' in the PHP configuration file. When a HTML error message was being generated, the output was not properly sanitized, which could allow an attacker to insert arbitrary HTML, thus allowing a XSS attack. This issue is only exploitable if 'html_errors' is on, which the configuration file cleary states should not be used on production machines. Sooooo... I wonder if this is the "bug" I've been thinking about for months, which is responsible for large amounts of so-called XSS in PHP applications that produce verbose error messages, e.g. when "&SearchIndex=' No "q" in sight. What gives? - Steve ====================================================== Name: CVE-2006-0334 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0334 Reference: MISC:http://osvdb.org/ref/22/22626-my_amazon.txt Reference: BID:16312 Reference: URL:http://www.securityfocus.com/bid/16312 Reference: FRSIRT:ADV-2006-0252 Reference: URL:http://www.frsirt.com/english/advisories/2006/0252 Reference: OSVDB:22626 Reference: URL:http://www.osvdb.org/22626 Reference: SECUNIA:18535 Reference: URL:http://secunia.com/advisories/18535 Cross-site scripting (XSS) vulnerability in search.php in My Amazon Store Manager 1.0 allows remote attackers to inject arbitrary web script or HTML via the Keywords parameter. NOTE: some sources claim that the affected parameter is "q", but the only public archive of the original researcher notification shows an XSS manipulation in "Keywords". From jericho at attrition.org Tue Jan 24 11:01:28 2006 From: jericho at attrition.org (security curmudgeon) Date: Tue, 24 Jan 2006 11:01:28 -0500 (EST) Subject: [VIM] vendor ack/fix: Aquifer CMS Index.asp Keyword Variable XSS (fwd) Message-ID: ---------- Forwarded message ---------- From: Brian Feldman To: moderators at osvdb.org Date: Mon, 23 Jan 2006 17:51:49 -0600 Subject: [OSVDB Mods] [Change Request] 22247: Aquifer CMS Index.asp Keyword Variable XSS Liquid Development, the makers of AquiferCMS, have released a security update to address this vulnerability. Support subscribers can contact their Liquid Development support team to request the update. Please visit www.aquifercms.com for more information. From jericho at attrition.org Tue Jan 24 13:44:13 2006 From: jericho at attrition.org (security curmudgeon) Date: Tue, 24 Jan 2006 13:44:13 -0500 (EST) Subject: [VIM] vendor ack/fix - OSVDB ID: 21716 (fwd) Message-ID: ---------- Forwarded message ---------- From: To: moderators at osvdb.org Date: Tue, 24 Jan 2006 13:28:59 -0500 Subject: [OSVDB Mods] OSVDB ID: 21716 Official reply from Kryptronic (developers of ClickCartPro): Kryptronic, developer of ClickCartPro software, has issued an update to all 5.0 and 5.1 version of ClickCartPro which combat this XSS vulnerability. More info here: http://www.clickcartpro.com/forum/index.php?showtopic=12172 Public statement concerning the update: This update contains modifications to the ClickCartPro codebase. These new codebase modifications create a wrapper for public CGI requests and strips characters from incoming formdata for those public CGI requests. The use of this wrapper prevents user submitted formdata containing HTML characters from being printed literally within the display routines. ClickCartPro has begun to fail tests performed by site scanning bots because of a positive return on cross-site-scripting tests. To ensure these tests are passed by your site in the future and to avoid security warnings from your hosting provider, we recommend you apply this update. Nick Hendler Kryptronic, Inc. Corporate: http://www.kryptronic.com/ Software: http://www.clickcartpro.com/ From coley at mitre.org Wed Jan 25 17:51:06 2006 From: coley at mitre.org (Steven M. Christey) Date: Wed, 25 Jan 2006 17:51:06 -0500 (EST) Subject: [VIM] The parameter in e-moBLOG is "monthy" [sic] Message-ID: <200601252251.k0PMp67r024443@cairo.mitre.org> Re: CVE-2006-0403 Various VDBs are mis-reading evuln's original report for the "monthly" parameter but, in fact, it's "monthy" (probably short for "month/year") A grep of index.php in e-moBLOG 1.3 demonstrates the point and also yields a source verification: >if (BLOG_LIMIT != 0 && (!$monthy || $monthy == "")) { ... >} else if ($monthy || $monthy != "") { ... > $wheremonth = "WHERE monthy = '$monthy'"; ... > $monthy = date("Ym"); ... > $wheremonth = "WHERE monthy = '$monthy'"; ... > echo "id . "\" title=\"" . $lang['link'] . "\">\n" and to show the SQL injection: > $result = execRequest("SELECT * FROM blogposts $wheremonth ORDER BY date DESC $blog_limit", $connection); and execRequest() (in includes/functions.php) has the requisite call to mysql_query() . - Steve From jericho at attrition.org Thu Jan 26 22:30:50 2006 From: jericho at attrition.org (security curmudgeon) Date: Thu, 26 Jan 2006 22:30:50 -0500 (EST) Subject: [VIM] My Amazon Store Manager 1.0 - q or Keywords parameter? In-Reply-To: <200601231852.k0NIq3FN028387@cairo.mitre.org> References: <200601231852.k0NIq3FN028387@cairo.mitre.org> Message-ID: : Refs: : : BID:16312 : FRSIRT:ADV-2006-0252 : SECUNIA:18535 : OSVDB:22626 : : Issue: : : These VDBs claim that the affected parameter is "q". : : I can't figure out where the VDBs got this, since there is no original : raw report. OSVDB thankfully has an archive of the notification here: : : MISC:http://osvdb.org/ref/22/22626-my_amazon.txt : : but it contains this demonstration URL: : : [hostname]musicstore/index.php?Operation=ItemSearch&Keywords=">&SearchIndex=' : : No "q" in sight. : : What gives? For OSVDB, this was us trusting Secunia since they tend to dig into some vulns more than we do. They reported 'q' which we trusted as the underlying issue. I'm going to change it back to Keywords until Secunia can confirm this. Bad move on my part originally. From vim at frsirt.com Fri Jan 27 07:16:42 2006 From: vim at frsirt.com (FrSIRT) Date: Fri, 27 Jan 2006 13:16:42 +0100 Subject: [VIM] My Amazon Store Manager 1.0 - q or Keywords parameter? Message-ID: <0b3a01c6233b$88e528c0$6400a8c0@FrSIRTLab23> Hello, The "Keywords" parameter is NOT affected by this issue (this parameter is reportedly used in My Amazon Store Manager v2.0 which is neither affected nor listed in our advisory). My Amazon Store Manager v1.0 (listed in our advisory) uses the "q" variable (confirmed as affected). http://www.frsirt.com/english/advisories/2006/0252 Regards, FrSIRT / French Security Incident Response Team 24x7 http://www.frsirt.com security curmudgeon wrote : : Refs: : : BID:16312 : FRSIRT:ADV-2006-0252 : SECUNIA:18535 : OSVDB:22626 : : Issue: : : These VDBs claim that the affected parameter is "q". From jericho at attrition.org Fri Jan 27 10:19:42 2006 From: jericho at attrition.org (security curmudgeon) Date: Fri, 27 Jan 2006 10:19:42 -0500 (EST) Subject: [VIM] Timecan CMS = in house service, not a sellable product Message-ID: ---------- Forwarded message ---------- From: Markku Alikoski To: 'security curmudgeon' Date: Fri, 27 Jan 2006 10:38:23 +0200 Subject: RE: [OSVDB Mods] About reported vulnerability Hi Brian, that's the case - Timecan CMS is an in-house production tool. All installed versions of Timecan CMS are running on servers maintained by our company. Idea Development ID is an privately owned B2B advertising agency and we are providing contentent management and web campaigning as an additional service for our clients. Timecan CMS is a tool I have developed to: -allow our no-tech creative staff set up web sites fast -produce web metrics and reports that make sense for our marketing dept. -execute and follow print, banner and e-mail campaigns for our B2B clients The mechanism how we got reported on several security sites is unfamiliar to me, but who ever it was, he / she was right - there was a possibility for injection. Given that: -there are only a handfull of query parameters that the system is reacting to -all querying is handled by a single function it was relatively easy to patch the system by validating the query string input before processing. Regards, Markku Alikoski System Architect Idea Development ID Ltd. Aurakatu 3 B FI-20100 Turku Finland Mobile +358 40 571 8172 Phone +358 2 8145 0707 markku.alikoski at idbbn.fi http://www.idbbn.fi -----Original Message----- From: security curmudgeon [mailto:jericho at attrition.org] Sent: Friday, January 27, 2006 5:51 AM To: Markku Alikoski Cc: moderators at osvdb.org Subject: Re: [OSVDB Mods] About reported vulnerability Hi Markku, : concerning reported vulnerability http://www.osvdb.org/22252 : An upgrade exists and is already installed on all running versions of : Timecan CMS. Can you provide a little more information? Your wording makes it sound like the CMS has an auto-update feature, or all the Timecan CMS sites are managed by you, else how would you know that all running versions were upgraded. Is that the case? If you could share a little more information about your product I would appreciate it. Brian OSVDB.org From jericho at attrition.org Fri Jan 27 11:39:38 2006 From: jericho at attrition.org (security curmudgeon) Date: Fri, 27 Jan 2006 11:39:38 -0500 (EST) Subject: [VIM] vendor confirms versions: iNETstore E Commerce Solution - Cross Site Scripting (fwd) Message-ID: ---------- Forwarded message ---------- From: iNETstore Support To: security curmudgeon Date: Fri, 27 Jan 2006 18:07:06 +1100 Subject: Re: [OSVDB Mods] iNETstore E Commerce Solution - Cross Site Scripting version 2.0. version 1.0 did not have the problem. thanks, iNETstore Support > : By a patch that can be applied. All registered users of iNETstore Online > : have been upgraded. > > I have updated the solution for OSVDB 22251 to reflect this. Can you > confirm which versions were affected by this? > > Thanks! > > Brian > OSVDB.org From coley at mitre.org Fri Jan 27 17:05:12 2006 From: coley at mitre.org (Steven M. Christey) Date: Fri, 27 Jan 2006 17:05:12 -0500 (EST) Subject: [VIM] Source VERIFY of CityPost PHP Upload message parameter XSS Message-ID: <200601272205.k0RM5C2l013702@cairo.mitre.org> Ref: SECTRACK:103752 Using the file downloaded from: http://tech.tailoredweb.com/download.php?f=/simple-upload-53/simple-upload-53.php [31] $message =""; So no global variable overwrite. [69] //File Size Check [70] if ( $_FILES['userfile']['size'] > $MAX_SIZE) [71] $message = "The file size is over 2MB."; various error conditions cause $message to be set to some error message. There are a number of code snippets like this one. [79] print ""; Oh, so it redirects using the message that was just set... slightly unusual, but alright. [127] Alrighty then, we have direct injection from a message parameter. - Steve From coley at mitre.org Fri Jan 27 17:09:09 2006 From: coley at mitre.org (Steven M. Christey) Date: Fri, 27 Jan 2006 17:09:09 -0500 (EST) Subject: [VIM] Source VERIFY of CityPost LNKX msg XSS Message-ID: <200601272209.k0RM99HA013734@cairo.mitre.org> Ref: SECTRACK:103752 Using the file downloaded from: http://tech.tailoredweb.com/download.php?f=/link-exchange-52/link-exchange-52.zip It's not clear what the actual version number is, though. from message.php: [1] there's no PHP in this file. > bingo. - Steve From jericho at attrition.org Sat Jan 28 01:40:01 2006 From: jericho at attrition.org (security curmudgeon) Date: Sat, 28 Jan 2006 01:40:01 -0500 (EST) Subject: [VIM] My Little Homepage Message-ID: ---------- Forwarded message ---------- From: Thorsten Fischer To: moderators at osvdb.org Date: Sat, 28 Jan 2006 01:28:54 +0000 Subject: [OSVDB Mods] 22753 Aloha. Mangling 22753. The 'My Little Homepage' vulnerability is rubbish. The name of the website is actually 'My Little Homepage', and there is 'My Little Forum' and 'My Little Guestbook'. The name of the software is actually 'phpSQLiteCMS'. It's therefore not 'multiple product', but just 'phpSQLiteCMS'. Someone probably wants to adjust the title :) I mangled it so far assuming that it's called 'phpSQLiteCMS'. Cheers, t From jericho at attrition.org Mon Jan 30 17:15:07 2006 From: jericho at attrition.org (security curmudgeon) Date: Mon, 30 Jan 2006 17:15:07 -0500 (EST) Subject: [VIM] Etomite followup information Message-ID: ---------- Forwarded message ---------- From: Rick Elnor To: moderators at osvdb.org Date: Sun, 29 Jan 2006 10:11:08 -0800 Subject: [OSVDB Mods] [Change Request] 22693: Etomite todo.inc.php cij Variable Arbitrary Command Execution Hello, I am Rick Elnor, the Etomite CMS security expert and owner ow Nixbased Security Consulting. I have noticed you reported the Etomite cij Variable Arbitrary Command Execution Vulnerability on your website. This information is not accurate. Heres the truth: "The eto site got hacked - they downloaded the etomite v0.6.0 files, and implemented a security exploit into them on the 11th of January, and reuploaded to the eto server. They also did the same with the RC3 files. The RTM files have been unaffected, as they are held on the secondary eto server. If you downloaded Etomite v0.6.0 prior to the 10th of January, your etomite install is safe. If you downloaded Etomite v0.6.0 or v0.6.1 RC3 after the 10th of January, your install may be compromised and you should upgrade to the RTM immediately. The second issue (which we knew about from day 1) - which is now completely irrelevant anyway (they made the code look like the "phone home" feature of etomite which is why we thought the issues were related). What the Phone Home feature does is phone home to the etomite server and tell us where you are running your etomite install ONLY if you untick the License Agreement box on the login page. THIS IS THE ONLY TIME v0.6.0 SENT US ANY DATA. We no longer collect the data, as I have removed the datacollection script." The above was posted as a forum message on the Etomite forums today at this location http://www.etomite.org/forums/index.php?showtopic=4291 From coley at mitre.org Mon Jan 30 19:55:33 2006 From: coley at mitre.org (Steven M. Christey) Date: Mon, 30 Jan 2006 19:55:33 -0500 (EST) Subject: [VIM] My Little Homepage - source verify of different products Message-ID: <200601310055.k0V0tXvd012883@cairo.mitre.org> Not sure I fully agree with this: >The name of the website is actually 'My Little Homepage', and there is >'My Little Forum' and 'My Little Guestbook'. The name of the software >is actually 'phpSQLiteCMS'. It's therefore not 'multiple product' There are separate product downloads, and the same bbcode() function, which is copied *almost* verbatim across products, but with slight differences in each product. A short list of products and relevant code follows. - Steve ======================================================================== my little weblog http://www.mylittlehomepage.net/my_little_weblog textfile version: http://www.mylittlehomepage.net/downloads/weblog.zip Looking at the weblog product, we have weblog.php, which includes: > $string = preg_replace("#\[link\](.+?)\[/link\]#is", "\\1", $string); > $string = preg_replace("#\[link=(.+?)\](.+?)\[/link\]#is", "\\2", $string); Assuming an input of: [link]javascript:alert('hi')[/link] It would appear to produce: javascript:alert('hi') based on the first preg_replace() above. This aligns with evuln's sample exploit. ** NOTE ** this is only based on source inspection and a non-100% complete understanding of PHP preg_replace() ======================================================================== my little guestbook http://www.mylittlehomepage.net/my_little_guestbook download: http://www.mylittlehomepage.net/downloads/guestbook.zip relevant file: guestbook.php - bbcode() vulnerable code, lines 95 through 101: >function bbcode($string) >... > $string = preg_replace("#\[link\](.+?)\[/link\]#is", "\\1", $string); > $string = preg_replace("#\[link=(.+?)\](.+?)\[/link\]#is", "\\2", $string); NOTE: a "diff" of this bbcode() function with my little forum's bbcode() function shows a slight difference. ======================================================================== my little forum http://www.mylittlehomepage.net/my_little_forum download: http://www.mylittlehomepage.net/downloads/forum.zip relevant file: functions.php Relevant source, lines 193-201: >function bbcode($string) ... > $string = preg_replace_callback("#\[link\](.+?)\[/link\]#is", "shorten_link", $string); > $string = preg_replace("#\[link=(.+?)\](.+?)\[/link\]#is", "\\2", $string); The shorten_link() callback function merely takes long links and replaces part of the link text with "...". NOTE: obviously this implementation of bbcode() is slightly different than the one in the other products, due to the use of preg_replace_callback. From coley at mitre.org Tue Jan 31 12:33:35 2006 From: coley at mitre.org (Steven M. Christey) Date: Tue, 31 Jan 2006 12:33:35 -0500 (EST) Subject: [VIM] MyBB search.php XSS: "sortordr" or "sorder" ? and vendor ACK Message-ID: <200601311733.k0VHXZmo019687@cairo.mitre.org> [vendor seems to have posted acknowledgement for multiple issues; see URLs below.] The MyBB search.php XSS reported by imei here (CVE-2006-0470): http://archives.neohapsis.com/archives/bugtraq/2006-01/0415.html says: cheknig of two input varibles "sortby" & "sortordr" in redirection page of search pages however, the demonstration exploit - which only shows an XSS manipulation of sortby - has a parameter named "sorder" in it. So is it "sortordr" or "sorder" ? The vendor seems to acknolwedge this here: http://community.mybboard.net/showthread.php?tid=6418 and the manual patch here is clear: http://community.mybboard.net/attachment.php?aid=2181 since it includes: $mybb->input['sortby'] = htmlspecialchars($mybb->input['sortby']); $mybb->input['sortordr'] = htmlspecialchars($mybb->input['sortordr']); So this must be, in fact, "sortordr". A grep of all code from the manual patch shows nothing relevant to "sorder". The patch also appears to affect the usercp.php/notepad vector (CVE-2006-0442) and the definition of the $op variable in the search.php fix *might* be relevant to CVE-2006-0406. There also appears to be an SQL-injection related fix in global.php, but I'm not sure where it came from - possibly a zero-day exploit. - Steve