Posts in R&D
Take 5 Minutes to Help Privacy Research!
This is from our colleagues at NCSU, and is time-critical. Please take 5 minutes to fill out this (simple) survey. It will help an NSF-funded privacy project.. And “Thank you” from CERIAS, too!
ThePrivacyPlace.Org Privacy Survey is Underway!
Researchers at ThePrivacyPlace.Org are conducting an online survey about privacy policies and user values. The survey is supported by an NSF ITR grant (National Science Foundation Information Technology Research) and was first offered in 2002. We are offering the survey again in 2008 to reveal how user values have changed over the intervening years. The survey results will help organizations ensure their website privacy practices are aligned with current consumer values.
The URL is: http://theprivacyplace.org/currentsurvey
We need to attract several thousand respondents, and would be most appreciative if you would consider helping us get the word out about the survey, which takes about 5 to 10 minutes to complete. The results will be made available via our project website (http://www.theprivacyplace.org/).
Prizes include
$100 Amazon.com gift certificates sponsored by Intel Co.
and
IBM gifts
On behalf of the research staff at ThePrivacyPlace.Org, thank you!
PHPSecInfo talk at OSCON 2008
If you’re at OSCON, and you love security, you may or may not enjoy my talk on PHPSecInfo, a security auditing tool for the PHP environment. I’m actually going to try to show some new code, so if you’ve seen it before, you can see it again – for the first time.
The talk is at 1:45pm Thursday, 07/24/2008.
RuxSeed v. 1.0 Released: A Ruby Open Source XCCDF Loader
I am happy to announce that ruxseed v. 1.0 is now available on SourceForge. Ruxseed processes XCCDF documents used for SCAP (NIST Security Content Automation Protocol) checklists. It performs benchmark resolution, i.e., the 6 “Loading” steps. Given an XCCDF document, it returns a resolved benchmark in the form of an ReXML tree. The project also contains a number of tests that might be useful to someone developing an XCCDF product.
This release enables work on more complex XCCDF processing, such as tailoring and compliance checking. If you would be interested in that functionality, and are willing to test or contribute code or test cases, please contact me.
This Week at CERIAS
Lots of new papers added this week—more that we can list here. Check the Reports and Papers Archive for more.
CERIAS Reports & Papers
CERIAS Weblogs
Cassandra Vulnerability Updates
The Cassandra system has been much more successful and long lasting than I first imagined. Being inexperienced at the time, there were some things I got wrong, such as deleting inactive accounts (I stopped that very quickly as it made many people unhappy or unwilling to use the service), or deleting accounts that bounced several emails (several years ago this was changed to simply invalidating the email address). Recently I improved it by adding GPG signatures. Email notifications from Cassandra are now cryptographically signed. The public key is available on the standard public key servers, such as the MIT server.
Things can still be improved
I initially envisioned profiles as being updated regularly, perhaps with automated tools listing the applications installed on a system. I also thought that there were many applications without vulnerability entries in MITRE’s CVE, the National Vulnerability Database (NVD, used to be named ICAT), or Secunia so I needed to let people enter product and vendor names that weren’t linked to any vulnerabilities. However, I found that there was little correlation between the names of products in these sources, as well as between those provided by scanning tools or entered manually by users. ICAT in particular used to be quite bad for using inconsistent or misspelled names. Secunia does not separate vendor names from products and uses different names than the NVD, so Cassandra has to guess which is which based on already known vendor and product names. Because of this, Secunia entries may need reparsing when new names are learned. So, users could get a false sense of security by entering the name of the products they use, but never get notified because of a mismatch! On top of it, bad names are listed by the autocomplete feature, so users can be mislead by someone else’s mistakes or misfortune. A Cassandra feature that helped somewhat with this problem was the notion of canonical and variant names. All variants point to a single canonical name for a vendor or a product. However, these need to be entered manually and maintained over time, so I didn’t enter many.
It gets worse. Profiles are quite static in practice; this leads to other problems. Companies merge, get bought or otherwise change names. Sometimes companies also decide to change the names of their products for other reasons, or names are changed in the NVD. So, profiles can silently drift off-course and not give the alerts needed. All these factors result in product or vendor names in Cassandra that don’t point to any vulnerability entries. I call these names “orphans”; I recently realized that Cassandra contained hundreds of orphaned names.
And they will be improved
I am planning on implementing two new features in Cassandra: Profile auto-correction and product name vetting.
- Auto-correction: If Cassandra recognizes a name change in the NVD or Secunia, or if it changes the way it recognizes vendor names from products in Secunia, it will attempt to change matching entries in your profiles.
- Vetting: all the product names in Cassandra will be verified to point to at least one entry in the NVD or Secunia; those that don’t and can’t be updated will get deleted. This means that when you create a new profile, Cassandra won’t suggest an “orphaned” name. If your profile contains an orphaned name that gets deleted, you should receive an email if you have email notifications turned on.
Note that you should still verify your profiles periodically, because Cassandra will not detect all name changes—this is difficult because a name change may look just like a new product. If you have a product name that isn’t in Cassandra, I suggest using the keywords feature. Cassandra will then search the title and description of the entries to find matches (note to self: pehaps keywords should search product and vendor names as well—that would help catch all variants of a name. Also, consider using string matching algorithms to recognize names).
This Week at CERIAS
CERIAS Reports & Papers
-
30 April 2007, 7:00 pm -
29 April 2007, 7:00 pm -
28 April 2007, 7:00 pm -
28 April 2007, 7:00 pm
CERIAS Weblogs
-
3 May 2007, 3:10 pm -
1 May 2007, 1:11 pm -
27 April 2007, 1:27 pm
The Vulnerability Protection Racket
TippingPoint’s Zero Day Initiative (ZDI) gives interesting data. TippingPoint’s ZDI has made public its “disclosure pipeline” on August 28, 2006. As of today, it has 49 vulnerabilities from independent researchers, which have been waiting on average 114 days for a fix. There are also 12 vulnerabilities from TippingPoint’s researchers as well. With those included, the average waiting time for a fix is 122 days, or about 4 months! Moreover, 56 out of 61 are high severity vulnerabilities. These are from high profile vendors: Microsoft, HP, Novell, Apple, IBM Tivoli, Symantec, Computer Associates, Oracle… Some high severity issues have been languishing for more than 9 months.
Hum. ZDI is supposed to be a “best-of-breed model for rewarding security researchers for responsibly disclosing discovered vulnerabilities. “ How is it responsible to take 9 months to fix a known but secret high severity vulnerability? It’s not directly ZDI’s fault that the vendors are taking so long, but then it’s not providing much incentive either to the vendors. This suggests that programs like ZDI’s have a pernicious effect. They buy the information from researchers, who are then forbidden from disclosing the vulnerabilities. More vulnerabilities are found due to the monetary incentive, but only people paying for protection services have any peace of mind. The software vendors don’t care much, as the vulnerabilities remain secret. The rest of us are worse off than before because more vulnerabilities remain secret for an unreasonable length of time.
Interestingly, this is what was predicted several years ago in “Market for Software Vulnerabilities? Think Again” (2005) Kannan K and Telang R, Management Science 51, pp. 726-740. The model predicted worse social consequences from these programs than no vulnerability handling at all due to races with crackers, increased vulnerability volume, and unequal protection of targets. This makes another conclusion of the paper interesting and likely valid: CERT/CC offering rewards to vulnerability discoverers should provide the best outcomes, because information would be shared systematically and equally. I would add that CERT/CC is also in a good position to find out if a vulnerability is being exploited in the wild, in which case it can release an advisory and make vulnerability information public sooner. A vendor like TippingPoint has a conflict of interest in doing so, because it decreases the value of their protection services.
I tip my hat to TippingPoint for making their pipeline information public. However, because they provide no deadlines to vendors or incentives for responsibly patching the vulnerabilities, the very existence of their services and similar ones from other vendors are hurting those who don’t subscribe. That’s what makes vulnerability protection services a racket.
PHPSecInfo v0.2 now available
The newest version of PHPSecInfo, version 0.2, is now available. Here are the major changes:
- Added link to “more info” in output. These lead to pages on the phpsec.org site giving more details on the test and what to do if you have a problem
- Modified CSS to improve readability and avoid license issue with PHP (the old CSS was derived from the output of
phpinfo()) - New test:
PhpSecInfo_Test_Session_Save_Path - Added display of “current” and “recommended” settings in test result output
- Various minor changes and bug fixes; see the CHANGELOG for details
-Download now
-Join the mailing list
What’s New at CERIAS
I haven’t posted an update lately of new content on our site, so here’s a bit of a make-up post:
CERIAS Reports & Papers
-
17 January 2007, 11:00 pm -
17 January 2007, 11:00 pm -
22 January 2007, 11:00 pm
CERIAS Hotlist
-
31 January 2007, 7:09 am -
29 January 2007, 9:10 am
CERIAS News
-
25 January 2007, 9:32 am -
8 February 2007, 10:22 am -
15 February 2007, 2:40 pm -
19 February 2007, 1:09 pm
CERIAS Security Seminar Podcast
-
17 January 2007, 3:30 pm -
24 January 2007, 3:30 pm -
31 January 2007, 3:30 pm
2007: The year of the 9,999 vulnerabilities?
A look at the National Vulnerability Database statistics will reveal that the number of vulnerabilities found yearly has greatly increased since 2003:
| Year | Vulnerabilities | %Increase |
|---|---|---|
| 2002 | 1959 | N/A |
| 2003 | 1281 | -35% |
| 2004 | 2367 | 85% |
| 2005 | 4876 | 106% |
| 2006 | 6605 | 35% |
Average yearly increase (including the 2002-2003 decline): 48%
6605*1.48= 9775
So, that’s not quite 9999, but fairly close. There’s enough variance that hitting 9999 in 2007 seems a plausible event. If not in 2007, then it seems likely that we’ll hit 9999 in 2008. So, what does it matter?
MITRE’s CVE effort uses a numbering scheme for vulnerabilities that can accomodate only 9999 vulnerabilities: CVE-YEAR-XXXX. Many products and vulnerability databases that are CVE-compatible (e.g., my own Cassandra service, CIRDB, etc...) use a field of fixed size just big enough for that format. We’re facing a problem similar, although much smaller in scope, to the year-2000 overflow. When the board of editors of the CVE was formed, the total number of vulnerabilities known, not those found yearly, was in the hundreds. A yearly number of 9999 seemed astronomical; I’m sure that anyone who would have brought up that as a concern back then would have been laughed at. I felt at the time that it would take a security apocalypse to reach that. Yet there we are, and a fair warning to everyone using or developing CVE-compatible products.
Kudos to the National Vulnerability Database and the MITRE CVE teams for keeping up under the onslaught. I’m impressed.
