[tptacek]

A reminder that a big part of the subtext of this piece is a reactionary movement against vulnerability research that Ranum was at the vanguard of. Along with Schneier, Ranum spent a lot of energy railing against people who found and exploited vulnerabilities (as you can see from items #2, #3, and #4). It hasn't aged well.

I'm not sure there's anything true on this list that is, in 2023, interesting; maybe you could argue they were in 2005.

The irony is, Ranum went on to work at Tenable, which is itself a firm that violates most of these tenets.

[diamondo25]

I've read about 80% of this page, and eventually stopped at the part where he says that the next generation will be more cautious. This, in my opinion, is false. Most software has simplified for user experience, and has not helped kids in the slightest bit. Its more addictive than ever, and all caution gets thrown out of the window when we let kids browse youtube unsupervised. Heck, a wrong search query or random text can give you NSFW content. And with the rise of shorts/stories/tiktoks you'll be molded by the algorithms. You don't or have barely any control over the content you see. If it notices you watch, what, 5 seconds? of a clip, it'll start recommending that.

The issues we have nowadays are different than those in 2005. People that havent seen the bad parts of the internet, will not teach their kids about it either...

[eduction]

> It hasn't aged well.

You’re wrong, it’s aged quite well.

Just take as one important set of examples the new mobile operating systems since this piece was published. Even the most thoughtfully designed and locked down (even with hardware, various uses of encryption etc) continue to have vulnerabilities at the base layer year after year. Bug hunting looks every year more and more like just an expensive sport for condescending security experts who think little about the broader context in which they operate. As much as we all appreciate the whack a mole.

Where there has been genuine security improvement is where we’ve taken the structural, locked down approach advocated here (see also djb’s paper about qmail security). iOS and Android apps (particularly the former) seem genuinely more secure than most desktop apps because they are structured to have very limited permissions from day one. The app environments on those systems looks like they were designed with many of the principles from this post expressly in mind.

The lessons for the OS layer seem obvious. Qubes and in particular Joanna’s post about “Qubes Air” point in one very promising direction.

[UncleMeat]

Offensive research is what motivates lessons for the OS layer. Look at the struggles were are having with things like kernel-level memory safety even when we can point at mountains of CVEs found by white hats. The community would be dragging its feet even more if the shared consensus was that actually it is really hard to beat ASLR and DEP so we are all done and have solved it.

[tptacek]

One of the major points of the qmail paper is that the structural locked down approach wasn't successful.

(I disagree with the paper in this regard, but it's a weird thing to hang your argument against vulnerability research on).

Georgi Guninski would have a thing or two to say about the applicability of vulnerability research to djb software.

[eduction]

Hi, that’s an interesting assertion but not actually accurate. It is vaguely related to the truth; djb acknowledges that qmail failed to partition in the way he advocates in the paper but says it survived without serious security issues for other reasons:

“ I failed to place any of the qmail code into untrusted pris- ons. Bugs anywhere in the code could have been security holes. The way that qmail survived this failure was by hav- ing very few bugs, as discussed in Sections 3 and 4.”

That’s very different from saying the approach wasn’t successful. It was just not tried (by him). My point is it has been tried in other ways since and seems to be working. To me at least!

(Also you took something I put in parens midway through my post with the opening words “see also” and said I “hang” my argument on it - ok, again interesting, not taking it personally as I’m sure you didn’t mean anything by it!)

[tptacek]

It didn't "survive" in that manner: it wasn't LP64 clean, and had memory corruption vulnerabilities.

[eduction]

You described something the qmail paper said and I corrected you. If the paper is inaccurate that’s orthogonal.

[tptacek]

You're also incorrect about the paper.

Really, the whole argument you're making --- the reason we're talking about Bernstein in the first place --- is broken. Bernstein himself would probably not agree with the take you're trying to derive from the relationship between his work and "enumerating badness".

[wildmanx]

> > It hasn't aged well.

> You’re wrong, it’s aged quite well.

Part of the problem is that there are many people in the field of security with overly strong opinions. This is not healthy. The field is full of know-it-all people, with if-only-people-were-not-as-dumb kind of attitudes. This is not helping anybody. Any not-as-strongly-opinionated bystander looks at this and has no clue whom to listen to, since so many people are strongly expressing 100% opposing views. Calling everybody else "dumb". This is not helpful to bring the field as a whole forward.

[rfoo]

> (see also djb’s paper about qmail security)

You mean the guy who refused to fix an integer overflow bug, claiming it isn't practical to exploit then 64-bit really happened then years later suddenly the fine guys at Qualys decided to have fun? [1] Sure, he is a crypto expert and we're all grateful for his work on curve25519, salsa/chacha, nacl, djbsort, etc (and I'm sure I missed a lot). This does not mean he is an expert on weird machine.

[1] https://www.qualys.com/2020/05/19/cve-2005-1513/remote-code-...

[eduction]

No, I don’t mean the guy. I mean the paper.

[autokad]

I agree. they go onto a useless rant about how pen testing is useless, red team research only enables hackers, etc. That's not true at all. That work is what pushes the improvements in both detection and better programming practices.

Educating users is not dumb, its one of the most important parts of security a company should address. I really don't know where they are coming from here, this section was nonsense to me.

I also have a point that will get me downloaded and piss off a lot of people, Security is very important, but not THAT important. If the business doesn't operate, then there's no need for security. So what's the solution? The author comes off as one of those that treat security like a wheelbarrow full of bricks that everyone has to push around. This wont get buy in and people will find ways around it. Instead, security should be like tennis shoes. restrictive but they also allow you to run faster.

[mavhc]

It's dumb to create a system will fail because of dumb users, why did you invent a system that required everyone using it not to be an idiot, have you never met humans?

[pvg]

What was the argument against vuln research? The 'Penetrate & Patch' bit makes it sound it's something like 'this is pointless because the proper way to fix this stuff is better design and other things are a waste of time and effort'.

[castillar76]

This predated a lot of the responsible-disclosure culture that exists now, so there was a lot of “find vuln, post right away for the credits” going on. Couple that with a lot of tool research that was important but also felt very grey-hat, and it was easy to feel like much of the “vulnerability research” community were like a group of scientists working on making cancer airborne “for research purposes”. I admit to having felt that way then, too.

Fortunately a lot of that has subsided. The focus on responsible disclosure while still holding companies accountable, the great security research being done by projects like Talos or Project Zero, and the consistent flow of new open-source blue-team tooling has really helped balance the scales (if they were ever unbalanced).

[tptacek]

This is a whole can of worms, and my response will be biased and untrustworthy, but here's my take:

In the early-to-mid 1990s, serious security research was intensely cliquish. There wasn't a norm of published vulnerability research; in fact, there was the opposite norm: CERT, the well-known public resource, diligently stripped details about vulnerabilities (beyond where to find the patches) out of announcements, and discussions about how vulnerabilities actually worked was relegated to "secret" lists like Core, which were of course ultimately leaked to became BBS tfiles.

Ranum came to prominence in that era. In the mid-to-late 1990s, after Bugtraq took over, there remained a sort of informal best friends club of, like, Ranum and Dan Farmer and Wietse Venema and like one or two young vulnerability researchers --- Elias "Aleph One" Levy, for instance. There was a sort of acceptance of the idea that Elias and Mudge were doing vulnerability research that was well-intentioned and OK... but that everyone else was just trading exploits on #hack.

There was a sort of focused beam of hatred on eEye, a security vendor that came to prominence in the early 2000s, and most especially during the "Summer of Worms", some of which worms were based on vulnerabilities that eEye's team --- at the time truly one of the most influential teams in all of vulnerability research --- had published. I worked at the industry's first commercial vulnerability research team and had a soft spot for eEye, which was doing the work we did but like several levels better than us, and it has always pissed me off how Ranum and Schneier tried to make hay by dunking on eEye and casting them as "hackers".

(Of course, if you tried to make that argument now you'd sound like a clown, so you won't see people like Ranum and Schneier saying that kind of stuff. But the fact is, the arguments were clownish and inappropriate back then, too.)

So, if you ask me, the argument Ranum is advancing is literally that public vulnerability research is bad, and that details of vulnerabilities should be kept between vendors and a few anointed 3rd party researchers. Because otherwise, you were just helping people break into computers.

The Ranum of 2005 is I think especially characteristic of what I'd call "moralizing" information security; that security is actually a fight between good and evil, that what's important about machines getting owned up is that somebody's livelihood depends on that machine running, and the hacking is a crime, and the details of how the hack worked are about as relevant as the details of how a burglar breaks into the window of a house they're burgling without setting off the alarms or whatever. I get it, but I'm from the opposing school of information security, which is that security is just a super interesting computer science problem.

[pvg]

I thought when asking to maybe snarkthrow in a 'this wasn't about disclosure, was it' but then I thought I would sound like a clown asking such a thing about a piece from 2005. Entirely externally/cluelessly my impression (at the time and since) was this was settled in the 90s by things like Bugtraq - that disclosure aligns with the interests of users in critical ways that leaving it up to vendors doesn't and this easily trumps objections about 'responsibility'. I didn't know this went on for so much longer, thanks for the history!

[mytailorisrich]

> Ranum spent a lot of energy railing against people who found and exploited vulnerabilities

That's not at all what #2 says. "enumerating badness" is explained as trying to track everything that's 'bad' instead of what's not. It is claimed to be 'dumb' because what 'bad' is orders of magnitude larger and more complex than what's not.

[tptacek]

It's not what #2 says, it's just why he was saying it.

[nine_k]

I suppose the idea of denying by default (#1, #2) and the idea of defense in depth (mentioned at the end) aged well enough.

I'm not sure about educating users. It's obviously not going to be a bulletproof solution. But not educating users at all also does not seem right either: it's hard for a person to care about stuff they have no idea about.

[SAI_Peregrinus]

The better way is to make the secure path the easy path. You don't have to educate users to do something that makes their life harder, you can educate them in an easier way to do what they want. That's far more likely to stick.

Usability is a security issue; at the ultimate extreme a DoS attack is just creating a very poor user experience.

[rfoo]

Thanks for the context! I was too young to know these backstories.