Tag Archives: History

In our pursuit of a more complete historical record of vulnerabilities, we’re offering a bounty! We don’t want your 0-day really. OK sure we do, but we know you are stingy with that, so we’ll settle on your ~ 12,775 day exploits!

First, the bounty. This is coming out my pocket since it is legacy and doesn’t immediately benefit people using us as a vulnerability feed. As such, this isn’t going to be a profit center for you. In addition to the personal satisfaction of helping preserve history, shout outs on this blog and multiple Twitter feeds, I will send you something. Want a gift card for Amazon? Something else I have that you want? I’ll make my best effort to make it reasonably worth your while. I know it isn’t a cool $1,337 Google style unfortunately, but I will try!

Now, what am I after. Not “a” vulnerability, but any of several lists of vulnerabilities from decades ago. These were maintained in the 1980’s most likely, one of which was internal at the time. I am hoping that given the time that has passed, and that the vulnerabilities have long since been patched and most products EOL’d, they can be disclosed. If you don’t have a copy but know someone might, send me a virtual introduction please! Any lead that results in me getting my hands on a list will be rewarded in some fashion as well. If you have a copy but it is buried in a box in the garage, let me know. I will see about traveling to help you dig through junk to find it. Seriously, that is how bad I want these historic lists!

The targets:

The Unix Known Problem List (this was not one of the vendor-specific lists, but those may be groovy)

UC Santa Cruz hack method list

Mt. Xinu bug list (later than 4.2 or with more details than this copy)

Matt Bishop’s UNIX Hole List

Sun Microsystems Bug-List (internal at the time no doubt)

ISIS mail list archive (one run by Andrew Burt in 80’s)

Bjorn Satedevas’ systems administration mailing list archive

The “inner” Zardoz mail list archive (split from the main one, less members)

Bonus bounty:

Any public-referenced vulnerability before 1980 that we do not have in the database. I know there has to be more out there, help us find them!

Bonus bonus bounty (for SCADA types):

Any SCADA or ICS vulnerability before 1985-06-01!

That’s it! Pretty simple, but may require some digging mentally or physically.

Today, we pushed OSVDB 82447 which covers a backdoor in the Multics Operating System. For those not familiar with this old OS, there is an entire domain covering the fascinating history behind the development of Multics. OSVDB 82447 is titled “Multics Unspecified Third-party Backdoor” and gives an interesting insight into backdoors distributed by vendors. In this case, a third-party planted it, told the vendor, and Honeywell still distributed the operating system anyway. I encourage you to read the full paper by Lieutenant Colonel Roger R. Schell, a member of the tiger team that carried out the attack.

To summarize;

During a US Air Force sanctioned penetration test of mainframe computers, sometime before 1979, the tiger team ended up penetrating a Multics installation at Honeywell. In an account of what happened later, a paper said that the tiger team “modified the manufacturer’s master copy of the Multics operating system itself” and injected a backdoor. The backdoor code was described as being small, “fewer than 10 instructions out of 100,000″ and required a password for use. The report continues, saying that even though Honeywell was told it was there and how it worked, their technicians could not find it. Subsequently, the backdoor was distributed in future installations of Multics.

It would be interesting to know why Honeywell didn’t ask for, or didn’t receive, the specific modified code from the Air Force tiger team, and why they opted to distribute it to customers. Perhaps they thought if their own technicians couldn’t find the backdoor, no one else could. Even more interesting is why a tiger team was sanctioned to carry out a penetration test that not only gave them access to the “master copy” of Multics, but why they were allowed to actually place the backdoor there. When they heard Honeywell couldn’t find it, why didn’t they insist on ensuring it was removed before installation at customer locations? This brings a new twist to the ethics of penetration testing, at least in a historical context.

This post is the farthest thing from picking on or insulting CVE. They were running a VDB some four years before OSVDB entered the picture. More impressive, they operated with a level of transparency that no other VDB offered at the time. Early OSVDB entries suffered just as greatly as the early CVE entries, and we even had the benefit of four years to learn from their efforts. Reading the original CVE entries is a fun look at how it all began. This post is a brief light-hearted look at the past.

Vulnerabilities reported ten years ago, they have no impact on your customers. If they do, then you are woefully behind and your customers are desperately hanging on to legacy products, scared to upgrade. For vendors who have kept up on security and adopted a responsible and timely manner for handling security, open up your records. Share with the world the ten or more year old vulnerabilities. Let the security community get a better picture of the real number of vulnerabilities reported to you, specifically the ones that never appeared in your advisories. This includes off-beat denial of service crashes, difficult to reproduce memory corruption, silly issues that required some level of access to begin with and everything else.

Some researchers have begun to do this, sharing more details of older disclosures that had vague details. Simple Nomad posted earlier this year about several old bugs as well as cleared up some confusion (via e-mail) regarding the old Palmetto FTP vulnerabilities.

I know this is a pipe-dream, as companies don’t want to admit to the number of vulnerabilities in their products, even ten years ago. Doesn’t matter that they fought uphill battles to win over the media and consumers with promises of how their software development life cycle matured or how they learned from their past. No way a vendor will dump hundreds of previously unpublished vulnerabilities on the world. On the rare chance a vendor will realize this can only help their reputation by sharing information and contributing to the VDB and metrics communities.. send them in! moderators[at]osvdb.org

On December 20, 2005, I posted a contest looking for the oldest documented vulnerability. This generated a lot of interest and was posted to the FunSec Mail List which generated even more interest and information. It also lead to me spending more time digging through my own notes and archives, something I had been meaning to do for ages. Even after all this time, the list of old papers and resources I have to track down is daunting. Since it is an ongoing project, I am overdue in posting about the winner of this contest. Not only did he eventually lead me to the documentation referencing what we call “Multics System Text Editor Multiple Instance CTSS Password File Disclosure” (Jan 1, 1965), but during ongoing e-mail discussion we were able to uncover several more in 1972. For that, Ryan Russell is the winner of this contest. We’ll be sending him some OSVDB schwag in return for his time and research.

I’m sure there are vulnerabilities that were discovered and published before that. Does anyone have a copy of the old “Unix Bug List“? Some old t-file or email with an ancient vulnerability? Perhaps a changelog for a product as venerable as Sendmail? We want it, and we’ll reward you for it…

I’m not exactly sure what the reward will be yet. Maybe a gift certificate from one of your favorite shops, maybe some OSVDB swag, maybe something a little more silly, who knows. The rules of this contest:

The information must be somewhat specific. Sendmail can get away with ‘multiple issues’ and remain vague due to the extensive history behind the program. We need to know some detail about the vulnerability. “BSD 0.83beta had a vulnerability” will not cut it.

The vulnerability must be documented somewhere. No stories or second hand accounts will work. Changelogs, advisories, email or anything else that can help authenticate it is required.

It must be a solid vulnerability. Concerns, weaknesses and best practices won’t work.

Lastly, it must pass the general ‘BS’ test. If our cynical minds detect shenanigans, it doesn’t count.

That’s it! So, beat our two entries from August 23, 1981 and grab a minute of fame on this blog, our appreciation, bragging rights, and whatever reward we come up with. Mail submissions to moderators at osvdb dot org.