Linked by Thom Holwerda on Tue 1st Nov 2005 08:38 UTC, submitted by Spock
OpenBSD "We are pleased to announce the official release of OpenBSD 3.8. This is our 18th release on CD-ROM (and 19th via FTP). We remain proud of OpenBSD's record of eight years with only a single remote hole in the default install. As in our previous releases, 3.8 provides significant improvements, including new features, in nearly all areas of the system."
Thread beginning with comment 55366
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[8]: ONE remote hole?
by on Fri 4th Nov 2005 00:16 UTC in reply to "RE[7]: ONE remote hole?"

Member since:

"Having a hole that could, some time in the past, have been exploited doesn't count as a remote hole."

Of course it does, otherwise you can discount ever remote hole that has ever been fixed.

"You have to have a workable exploit on the current version (at the time)."

Why must the exploit have to be created at the time the vulnerability was first discovered? That makes no sense. A remote hole is a remote hole regardless of whether or not it's been exploited.

I'm sure that there still are lots of potential holes in the current distribution but the point is, they're so hard to find that nobody knows where they are or how to exploit them.

"if you find a hole in a daemon that has been disabled in the current version it doesn't count (or did they find that hole before 2.8 came out?)."

You don't understand, when the vulnerability was discovered in 2000, talkd was enabled by default. The OpenBSD team disabled talkd by default BECAUSE OF the discovery of the vulnerability.

"is != was. "

At the time when the vulnerability was discovered, talkd was enabled by default, so you can't discount it.

"And unless you can provide a proof of concept talkd exploit or prove that it's actually remotely exploitable the claim, for what it's worth, isnt invalid."

That makes no sense, why should the burden of proof be on me? No one has proven that it's NOT exploitable, so following your logic, I could conclude that it MUST be exploitable.

Reply Parent Score: 0