Vulnerability History

[This was originally published on the OSVDB blog.]

Steven Christey (CVE) recently posted about vulnerability history and complexity. The recent sendmail vulnerability has brought up discussion about both topics and adds another interesting piece of history to the venerable sendmail package. One point to walk away with is that while sendmail has a long history of vulnerabilities, the last five years have shown the product to be considerably more secure. While overflows still haunt the ~ 25 year old software package, they are growing fewer and requiring considerably more complex methods to exploit them. The latest discovery is by no means a run-of-the-mill remote overflow, rather it takes considerable skill to find and exploit the flaw.

Using vulnerability history to help evaluate the current security posture of software is a bit sketchy, but certainly helps. If a program starts out with standard overflows, race conditions, symlink issues, XSS or SQL injections, it’s basically expected. If years pass and new versions of the same package continue to exhibit the same coding practices that lead to these vulnerabilities, you begin to get an idea of the quality of code as it relates to security. On the other hand, if years pass and the vulnerabilities are published with more time between each, and the difficulty exploiting them increases, it shows the developers are security conscious and producing more secure code. As always, the lack of published vulnerabilities in a product doesn’t mean it is free from defect, just that they possibly have not been found or published.

Fun fact: The first documented Sendmail vulnerability was on Aug 23, 1981.

The Web Hacking Incidents Database

[This was originally published on the OSVDB blog.]

The Web Hacking Incidents Database

The web hacking incident database (WHID) is a Web Application Security Consortium project dedicated to maintaining a list of web applications related security incidents. WHID goal is to serve as a tool for raising awareness of the web application security problem and provide the information for statistical analysis of web applications security incidents.

The WHID is an interesting new database that seems to be a cross between a database of site specific vulnerabilities (something OSVDB has considered maintaining) and the Attrition Dataloss page.

Disclosure: Annuaire (Directory) Multiple Vulnerabilities

[This was originally published on OSVDB, now gone. VulnDB IDs 24302, 24303]

Comment left on feedback page:
http://www.brunox.org/modules.php?op=modload&name=FeedBack&file=index

While testing your demo of Annuaire (Directory), I noticed a few security vulnerabilities:

Many pages are calling /include/lang-en.php which is showing the full installation path. Additionally, directly requesting this script will reveal the full path.

inscription.php The comment field (COMMENTAIRE variable) allows for cross-site scripting (XSS) attacks.

Thanks

Brian

Disclosure: ARIA (Accounting Receiving and Inventory Administration) genmessage.php Message Field XSS

[This was originally published on OSVDB, now gone. VulnDB ID 24255]

From: security curmudgeon
To: jflechtner[at]users.sourceforge.net
Date: Tue, 28 Mar 2006 11:25:02 -0500 (EST)
Subject: ARIA security issue

Hey Josh,

Not sure if you are still maintaining this project, but while playing with the demo I noticed a small security issue. The genmessage.php script doesn’t sanitize user input submitted to the Message Field (message variable) allowing for cross-site scripting (XSS) attacks. I didn’t test the other scripts so this may occur in other scripts.

Thanks,

Brian

Microsoft Opens IE Bug Database

[This was originally published on the OSVDB blog.]

Microsoft Opens IE Bug Database

Microsoft has established a public database to allow Internet Explorer users to report bugs in the Web browser.

To post or view bugs, users must sign up for a Passport account on the Microsoft Connect Web site.

Microsoft plans to allow non-registered users to view reported bugs in a couple of months, according to a post on the Internet Explorer Weblog.

[..]

Microsoft is only accepting bug posts for Internet Explorer 7 and future versions.

The last line is curious. I understand a vendor’s motive for not supporting a product it considers old, and not updating it. I even understand a vendor saying “from here on out, no updates, including security updates”. However, MSIE6 will be heavily used for years to come, and will remain a large part of personal and corporate user installations. MSIE6 consists of a lot of code and represents a decade of work from Microsoft. Pointing out bugs in security or functionality should be of interest to them, even if they plan to completely ditch version 6. Such bugs would help them learn more about how the code is used and abused, and help them from making the same mistakes in future releases.

Disclosure: @1 Event Publisher / @1 Table Publisher Multiple Vulnerabilities

[This was originally published on OSVDB, now gone. VulnDB 24235, 24236, 24237, 24238]

  • Ticket has been submitted. The ticket number is SCR00994.

While looking at some of your scripts, I noticed there are a few security issues:

UPOINT @1 Event Publisher
eventpublisher_admin.htm does not validate input to the Event, Description, Time, Website, and Public Remarks fields. This can be used for cross-site scripting (XSS) attacks.

eventpublisher_usersubmit.htm does not validate input to the Event, Description, Time, Website, and Public Remarks fields. This can be used for cross-site scripting (XSS) attacks.

A direct request to eventpublisher.txt will reveal the contents of private comments

UPOINT @1 Table Publisher
tablepublisher.cgi does not validate input to the Title of Table field, which can be used for XSS attacks.

Thanks

Disclosure: Andy’s PHP Knowledgebase (aphpkb) Multiple Vulnerabilities

[This was originally published on OSVDB, now gone. VulnDB IDs 24310, 24311, 24312]

From: security curmudgeon
To: aphpkb-devel[at]lists.sourceforge.net
Date: Mon, 27 Mar 2006 12:32:18 -0500 (EST)
Subject: Andy’s PHP Knowledgebase (aphpkb) security vulnerability

Hi Andy,

While playing around with your knowledgebase program, I noticed that a few places didn’t sanitize user input, allowing for cross-site scripting (XSS) attacks. The following pages and variables are affected:

index.php keyword_list
submit_article.php title, article, author, keywords
submit_question.php Question, Name, Email

This was tested on version 0.57

On the Value of Automated Code Scanners

[This was originally published on the OSVDB blog.]

CodeScan Labs recently disclosed that their new product was used on ASP Portal to look for vulnerabilities. These types of scanners are automated and check for common programming errors that lead to vulnerabilities. These types of tools have been around for many years, but are starting to mature quickly. However, one has to wonder just how effective they can be:

2006-03-02 – ASP Portal announces version 3.1.0 which contains “CodeScan security fixes”
2006-03-03 – ASP Portal announces version 3.1.1 which contains “a critical security Fix” (in news_item.asp)
2006-03-14 – CodeScan discloses their tool found 10 SQL injections and over 50 cross-site scripting vulns
2006-03-20 – nukedx releases a working exploit for an SQL injection (in download_click.asp)
2006-03-21 – nukedx releases details for 10 SQL injections in 3.1.1 including one in news_item.asp

So CodeScan finds 10 SQL injections, but doesn’t find the 11 others that nukedx finds a week later, and doesn’t find the “critical” issue in news_item.asp either. Hopefully these tools continue to mature very quickly. Maybe some day, cross-site scripting vulnerabilities will be a thing of the past! Hah yeah right, if that were true, overflows and race conditions wouldn’t pop up every few days either.

Disclosure: gtd-php Multiple Vulnerabilities

[This was originally published on OSVDB, now gone. VulnDB IDs 24149, 24150, 24151, 24152, 24153, 24154, 24155, 24156, 24157, 24158]

From: security curmudgeon
To: sjrey[at]users.sourceforge.net
Date: Sun, 19 Mar 2006 22:42:24 -0500 (EST)
Subject: gtd input sanitization (XSS) vulnerabilities

Hey Serge,

While playing with the version 0.5 demo of gtd, I noticed that the program doesn’t sanitize user input in several places. This can allow for various forms of Cross-Site Scripting (XSS) attacks. Here are the places I noticed:

http://gtd-php.sourceforge.net/gtd/newProject.php
Description and Title Field
Script renders when listProjects.php is called, or any page that gives the Project drop down selection.

http://gtd-php.sourceforge.net/gtd/newList.php
Description and Title Field
Script renders when listList.php is called.

http://gtd-php.sourceforge.net/gtd/newWaitingOn.php
Description and Title Field
Script renders when listWaitingOn.php is called.

http://gtd-php.sourceforge.net/gtd/newChecklist.php
Title Field
Script renders when listChecklist.php is called.

http://gtd-php.sourceforge.net/gtd/newContext.php
Title Field
Script renders when reportContext.php is called.

http://gtd-php.sourceforge.net/gtd/newCategory.php
Category Name
Script renders when creating new items (any that list a category to select).

http://gtd-php.sourceforge.net/gtd/newGoal.php
Title Field
Script renders when listGoals.php is called.

Additionally, when playing around, some of the scripts would temporarily show output before redirecting to another page. These also render the script code, and can be called directly:

http://gtd-php.sourceforge.net/gtd/listReport.php?listID=3&listTitle=%3Cscript%3Ealert(document.cookie)%3C/script%3E%20347http://gtd-php.sourceforge.net/gtd/projectReport.php?projectId=7&projectName=%3Cscript%3Ealert(document.cookie)%3C/script%3E%20347http://gtd-php.sourceforge.net/gtd/checklistReport.php?checklistId=&checklistTitle=%3Cscript%3Ealert(document.cookie)%3C/script%3E%20347

Jericho

From: Serge Rey
To: security curmudgeon
Date: Sun, 19 Mar 2006 20:29:31 -0800
Subject: Re: gtd input sanitization (XSS) vulnerabilities

jericho,

thanks for taking the time to let me know about this.

i took the demo off-line for now.

we will add the filtering soon.

serge

Disclosure: Prayer Request Board (PRB) addRequest.php Request Field XSS

[This was originally published on OSVDB, now gone, and touched up slightly for style. VulnDB 23958]

From: security curmudgeon
To: todd(at)geekforgod.net
Date: Sun, 19 Mar 2006 20:40:21 -0500 (EST)
Subject: PRB small security vulnerability

Hey Todd,

When submitting a new prayer request (addRequest.php), the Request field doesn’t sanitize user input. This allows for cross-site scripting (XSS)
attacks. You can see a safe sample of it on the demo on geekforgod.net.

Jericho