Comment by ufmace | Hacker News Reader

Comment by ufmace | Hacker News Reader

I wonder how well we all think this article has aged?

"Penetrate and Patch" is supposedly dumb. But what do we practically do with that? We've seen in the last decade or so a lot of long-lived software everyone thought was secure get caught with massive security bugs. Well, once some software you depend on has infact been found to have a bug, what's there to do but patch it? If some software has never had a bug found in it, does that actually mean that it's secure, or just that no skilled hackers have ever really looked hard at it?

Also web browsers face a constant stream of security issues. But so what? What are we supposed to do instead? Any simpler version doesn't have the features we demand, so you're stuck in a boring corner of the world.

"Default Permit" - nice idea in most cases. I've never heard of a computer that's actually capable of only letting your most commonly used apps run though. It's not very clear how you'd do that, and ensure none of them were ever tampered with, or be able to do development involving frequently producing new binaries, or figure out how to make sure no malicious code ever took advantage of whatever mechanism you want to use to make app development not terrible. And everyone already gripes about how locked-down iOS devices are, wouldn't this mean making everything at least that locked down or more?

1. Default deny is one of the oldest best practices in security engineering; it barely needed saying in 1995 (but Cheswick & Bellovin said exactly that in Firewalls & Internet Security).

2. "Enumerating badness" is simultaneously an attempt to connect vulnerability research to antivirus (security practitioners have had contempt, mostly justified, for AV since the late 1980s) and an endorsement of the heuristic detection scheme companies like NFR sold. Apart from the shade it throws at vulnerability research, it's fine.

3. "Penetrate and patch" has aged so poorly that Ranum's own career refutes it; he ended up Chief of Security at Tenable, one of the industry's great popularizers of the idea.

4. "Hacking is cool": literally, this is "get off my lawn".

5. Objecting to user education is an idea that is coming back into vogue, especially with authentication and phishing. It's the idea that has held up best here.

6. "Action is better than inaction" --- this is just a restatement of "something must be done, this is something", or the Underpants Gnome thesis. Is it true? Sure, I guess.

As a whole, this piece has not aged well at all.

> Objecting to user education is an idea that is coming back into vogue, especially with authentication and phishing. It's the idea that has held up best here.

The notion that users can't really be educated has led to a lot of questionable security practices that prioritize ease of use over real security. For example, 2FA using codes sent by email or SMS as the second factor rather than relying on key based authentication like client side TLS certificates issued by the service that the client is using.

This, to some extent, has actually decreased security by allowing people to bypass authentication by compromising the second factor through use of social engineering.

My bank used client TLS certificates early on, while it is nifty it was a really bad idea without hardware security. (Paper OTP in their case)

IMHO, client side certificates are a big failure even on server to server. The UX of doing it is error prone and insecure because of foot guns. It fails because there are so many different incompatible ways to use them. Mostly this idea of mine is based on never having had a good experience with browser based client certificates (even highly automated and hardware secured ones). Things does not get much better on server.

Sure automation helps but the certificate is a such a small part of the system, and when you try to integrate two automated systems that use client side TLS certificates it is easy to trust too much or too little. (Both are troublesome)

Apple/etc Passkeys (WebAuthn in software instead of hardware tokens) seems similar to TLS client certs, so I'm sure the UX stuff with certs is solvable if anyone cared.

They are, but they require one to use the HTTP application level protocol. I would like to be able to do the same with SMTP and IMAP in my email client without having to make HTTP requests.

> The UX of doing it is error prone and insecure because of foot guns.

Many people over the years have mentioned UX issues as a reason why client side TLS certificates aren't more widely used. The question is why hasn't there been an effort to improve the UX rather than re-inventing the wheel (either poorly with SMS/email 2FA or OTP, or in a way that's limited to a specific application level protocol like HTTP for webauthn).

What I would like to see is a standard workflow where as part of an account creation process, an associated CSR is sent and a client side TLS cert is returned and stored on the device along with a standard way to add additional devices using an existing device and the new device that doesn't depend on a specific application level protocol (so, for example, I can use my email client via SMTP and IMAP to securely authenticate without having to rely on a HTTP intermediary).

Or, for more secure settings, actually having to verify your identity out of band (e.g., going to the bank and showing multiple forms of ID along with your CSR to get the certificate.

The problem is basically that it wasn’t a priority for application developers but you need to upgrade things everywhere before you can switch to a new protocol. Those clunky MFA options give CIOs the appealing promise that a bit of duct tape means they get some protection without needing to e.g. replace that old RADIUS server most people depend on to do their jobs.

It might be interesting to look at WebAuthn passkeys, as they do most of what you want. That took several important developments: the web ate desktop apps, Microsoft lost control of the web, and Google has some strong security people in their management. That does the public key exchange, has robust cross-device support which doesn’t require an internet connection, etc. and it has some features to improve the identity situation (e.g. it includes a device key & authentication info so my bank can say it only accepts transfer requests which came from a known device doing a biometric check, which is a nice edge over x509/SSH-style trust based solely on access to the private key).

This unfortunately does not work using other protocols but a not-uncommon flow would be using a browser session to issue your IMAP client a token. That’s not great (a compromise gives the attacker your email) but it can be less disastrous if the most important actions can’t be initiated purely from email.

> Objecting to user education is an idea that is coming back into vogue, especially with authentication and phishing. It's the idea that has held up best here.

This can be good or bad depending on how you do it. If you default to the good thing and there really isn’t any need to do the bad thing then it can be quite good. If there is a genuine need for some people to sometimes do the bad thing (so it’s not actually universally “bad”) pretending like nobody can ever make an informed decision here is not a good policy. Sure, it’s very difficult to get people to make informed choices, but you can’t really brush this off as people being uneducateable.

you can’t really brush this off as people being uneducateable

The objection isn't that people are uneducable, it's that even expert users can easily make seemingly-trivial mistakes which then have catastrophic consequences (e.g. experts get phished) and that's a conclusion reached through experience/data.

> 4. "Hacking is cool": literally, this is "get off my lawn".

I do not quite agree with this verdict. Back in the early two thousands there were lots of people who thought it rather cool to just hack around (or more precisely crack around), for example by exploiting SQL injection bugs in whatever web form they encountered.

Of course I might not have a representative impression of the community, but I think this kind of stuff is now much more widely seen as unethical and uncool. So I think the article's prediction that this will "be a dead idea in the next 10 years" was actually quite accurate.

It's actually hard to argue here given there is so much ambiguity.

Technically "hacking" is often portrait as totally cool and often not negatively connotated ("getting/being hacked" however clearly is). The problem with this is that the meaning has shifted a lot in the meantime. He means mostly cracking I think, while the meaning of "hacking" has shifted to be broadly just altering state/behavior often to something that was not originally intended.

At least he also includes penetration testing as something bad and this has clearly not aged well. For one you can also employ people to do just that and it's pretty essential for applications with big security implications and the other part is the invitation to "hack" the application/system at hand seen with bug bounty programs. The actual practice seems to contradict his point here.

You can also interpret it in a way that it is not going to improve your security just by virtue of having pen testing, which is true. However I feel like nobody argued that. Pen testing/bug bounties are there to actually get attention of exploits you might not get otherwise and therefore a prerequisite for fixing exploits. Or said differently: If you think you hardened your application/system so much that it's impenetrable, how could it hurt if people try to break it and tell you if they are able to. People will try anyway, but they might not tell you.

> 1. Default deny is one of the oldest best practices in security engineering; it barely needed saying in 1995 (but Cheswick & Bellovin said exactly that in Firewalls & Internet Security).

I agree with this as the theoretical grounding and certainly wouldn't say that this was especially insightful but I can understand why he said it if he was encountering a long tail of obsolete advice similar to what several places I worked were hearing at the time. I think one of the big problems was simply inertia: I remember the Cisco guys at one job saying they didn't want to do a default-deny policy because it was too much work to switch and they weren't sure if the hardware could handle that many rules.

Agree with tptacek. His rant in Enumerating Badness is deeply intertwined with his rant against Default Permit (which as tptacek points out, was a bit of a strawman even then). I could agree that checking against all possible bad things is a flawed approach for security products and IT staff.

However, enumerating badness is hugely valuable in the security industry for two reasons:

1) It’s the backbone of security research, just as physiology and anatomy are to zoology and medicine. With enumeration (observation), we can classify, abstract, find trends, identify risky software and approaches, direct engineering resources, and create broad defenses (yay ASLR).

2) Attackers are lazy, too. I work at a security consulting firm, and routinely see attackers reuse the same TTP across different target companies. Enumerating badness not only offers detection opportunities (perhaps not the best, but higher level detection techniques are often built off understanding the enumeration of badness) but also denies attackers opportunity for reuse. “Impose cost,” as thoughtlords like to say.

4/6 and it hasn't aged well?

1 might be ubiquitous even in 2005 but it's 2022 and this was the page that was shared, obviously it was worth Ranum stating...

The things that are true aren't interesting, and the things that are interesting aren't true.

> Also web browsers face a constant stream of security issues. But so what? What are we supposed to do instead? Any simpler version doesn't have the features we demand, so you're stuck in a boring corner of the world.

The charitable interpretation of the “penetrate and patch” section is the architectural parts, and browsers are a great example. At the time he wrote that, a browser was a single process running everything in traditional C/C++ calling other unsafe code (i.e. Flash) in the same process. People did patch a lot but they also did things like split components into separate processes with different privilege levels, change practices throughout the codebase to harden things like pointers or how memory is allocated, rewrite portions in memory-safe languages, etc. It took a decade but browsers became a lot harder to successfully exploit.

I think this article has aged very well.

> Also web browsers face a constant stream of security issues. What are we supposed to do instead?

There's not much that users can do, but web browsers have spent the last decade moving away from "Penetrate and Patch" to much more proactive approaches. Eg, Chrome pioneered moving each tab to a separate process with full sandbox isolation. Firefox is talking about using webassembly as an intermediate compilation step for 3rd party C++ code to effectively sandbox it at a compilation level. Rust was invented by Mozilla in large part because they wanted to solve memory corruption bugs in the browser in a systematic way.

> "Default Permit" - nice idea in most cases. I've never heard of a computer that's actually capable of only letting your most commonly used apps run though.

MacOS requires user consent for apps to access shared parts of the filesystem. The first time you see dialogues asking "Do you allow this app to open files in your Documents folder" its sort of annoying, but its a fantastic idea.

As you say, my iPhone is more secure than linux for the same reason - because iOS has a "default deny" attitude toward app permissions. A single malicious app (or a single malicious npm package) on linux can cryptolocker all my data without me knowing. The security model of iOS / Android doesn't allow that and thats a good thing.

I wish iOS was more open, but on the flipside I think linux could do a lot more to protect users from malicious code. I think there's plenty of middle ground here that we aren't even exploring. Linux's permission model can be changed. We have all the code - we just need to do the work.

Also since this article was written, we've seen a massive number of data breaches because MongoDB databases were accidentally exposed on the open internet. In retrospect, having a "default permit" policy for mongodb was a terrible idea.

The consumer OS lockdown side does have a lot of interesting points. One I also thought of - I'd bet that, even if we reject web browsers, basically every user's "30 most used apps" has at least one that has a plugin system that loads unverified code, or runs macros in some kind of interpreter that is or may later be proved to be exploitable, or parses structured data from files that can't be trusted using non-memory-safe code, or some other thing I haven't thought of.

> my iPhone is more secure than linux for the same reason

The phrase "more secure" doesn't mean anything, I wish it wasn't used.

One needs to talk about the threat model(s) you care about and how a particular solution addresses them (or not). Any given solution can be both more secure and less secure than an alternative, depending on what threat models you care about. Which may well be different than the threat models someone else cares about.

If you unconditionally trust Apple and all government agencies which have power over Apple (e.g. NSLs) then one could say iOS has a more secure file access model than Linux. But that's a big if. Personally I could never trust a closed source proprietary solution.

> The phrase "more secure" doesn't mean anything

Fair point. I'll elaborate:

The linux (UNIX) security model is designed to protect users from other (potentially malicious) users on the same computer. The system as a whole is designed such that a malicious (or incompetent) user can't make the system as a whole stop working. The system is more important than any particular users' data.

Software is assumed to be correct. Any program a user runs inherits the full permissions of that user.

There's some problems:

1. Computers aren't often shared between mutually-untrusted people.

2. My data is much more precious than my computer itself.

3. Malicious software is everywhere. Every time I install a package some stranger wrote on npm or Cargo, I implicitly give it full access to all my data and my entire network.

So, linux protects me from things I don't need protections from (other users) and doesn't protect me from things I do need protection from (malicious code).

> One needs to talk about the threat model(s) you care about and how a particular solution addresses them (or not).

The threat model for malicious code is, I install an apt package / cargo crate / npm package / intellij or vscode extension and the package contains code which either exfiltrates my data over the internet, or cryptolockers it.

iOS (and Android?) don't let code like this run, since software can only (by default) access the data that it itself has created. Ransomware attacks are trivial on linux and impossible on iOS.

Its much more likely that me or my family suffers from a keylogger or ransomware attack than we suffer as a result of government intrusion into our digital lives. I'm one bad npm install away from having all my data stolen, and it terrifies me.

Linux has lots of protective measures outside of just user isolation. There's capabilities, namespaces, cgroups, seccomp, landlock, selinux, apparmor.

The difference is Linux gives the owner of the machine (for better or worse) decide what to do here. There are distros that try to force you into a more secure posture (Qubes), though.

This is interesting to me. Do you know if Windows OS provides similar features? The ideal for corporate environments (outside of dev) would be desktops that operate in the same way as iOS.

In theory, yes.

https://learn.microsoft.com/en-us/windows/security/threat-pr...

The practical application of this is a different story.

But there is a problem with trying to compare this to things like iOS and phones. Phones are strongly application based, it is completely common to have your data locked up in an app and getting to another app has varying levels of difficulty.

In Windows it is much more common for data to be file based, and applications can be launched and ran by clicking the file. File security is based on the user, so typically any application can access files owned by the same user. A huge portion of workflows would break if this were not the case.

> Its much more likely that me or my family suffers from a keylogger or ransomware attack than we suffer as a result of government intrusion into our digital lives.

Are you sure? How would you know? We can't know how many people the government blackmails with data taken from their iphones, because it's illegal to publish information about them doing so, whereas ransomware attacks are widely publicised.

As key component of threat modelling is risk management and modelling.

I would counter the “government blackmailing people” by questioning the risk this poses to me as an individual. As much as we’d like to imagine it, and as much as it can often times feel like it, we don’t live in a Kafkaesque society, by and large, as the significant majority of us are of zero interest and have little of anything worth blackmailing.

It seems to be routine for rape complainants to have to hand over their phone and have their messages scrutinized, as a pre-requisite to proceeding with an investigation. That is a form of government blackmail.

I disagree entirely with that notion. If you make a serious accusation, you must be prepared to hand over the necessary evidence to assist the investigation and get a conviction. I'll also say that at that point, the risk has changed dramatically. Risk isn't a static thing. It needs to be assessed regularly and evaluated when your threat model changes. Your exposure to risk is still a factor.

> hand over the necessary evidence

Of course. But you shouldn't have to spill your guts about your entire life (I understand that young folk nowadays life their lives in Instagram selfies).

And more to the point, the first step for the policemen investigating a rape complaint should be to investigate the complaint, not the complainant. If the investigation of the complaint raises questions about the complainant, then there might be grounds for seizing the complainant's device. But they can't make device seizure a pre-requisite for doing their job.

This is rubbish. The police investigate the claim and based on the results of the investigation, the prosecutor decides whether charges can be laid. The prosecutor!

Not the police!

What? Where is this routine? Where do you live? What if you don't have a phone? Why would you give your phone to the police in this situation instead of the prosecutor?

Which government? What level? My god, who told you this thing? For what other crimes is this policy enforced?

> 3. Malicious software is everywhere. Every time I install a package some stranger wrote on npm or Cargo, I implicitly give it full access to all my data and my entire network.

This particular case wouldn't really be prevented by an Android/iOS-type security model, I think? That package will be part of the program you're writing, and chances are that program requires more than the bare-minimum access.

That said, it's not extraordinarily difficult to lock this down, if you really want to. Docker is common, but more traditional tools work as well (e.g. running your program as its own user, maybe in a chroot), and/or using cgroups directly.

This applies even more with things like VSCode extensions, which typically run inside the VSCode process, and without filesystem access VSCode is pretty useless.

The landscape of security switched from the computer to the user.

As user you need to become root in a way or another to install a system program or something that affects the system as a whole. And you are aware that you are doing something that affects the system as a whole. The security was meant for multiuser environments, the computers were shared in a way or another.

But what matters now about that computer (specially when you are the single user of it) is your user, your data, your credentials, your network access, etc, all that you as user (and app you run) can access, or modify. Viruses and malware in general used to be system threats, but it is enough to be user threats now.

Things are moving to containerized in a way or another applications (docker, snaps, whatever do iOS and Android with that, etc), with limited access to your data, credentials and so on.

> The first time you see dialogues asking "Do you allow this app to open files in your Documents folder" its sort of annoying, but its a fantastic idea.

It’s not a great idea because it’s annoying. It is not really useful in its current incarnation to most people.

Further, banner/modal fatigue is a real thing. People will just ignore and click through.

This is because the dialogs have gotten rid of the disclosure arrows that gave path information and metadata about the binary. Also, executables used to have names consistent with the naming conventions on the platform. Now you just get dialogs with some cryptic name, and a one line manpage.

> Chrome pioneered moving each tab to a separate process with full sandbox isolation.

I don't think it was done for security. Before chrome where all tabs ran in single process it was common for a bad site to stall your whole browser. Separating it into single processes was basically admission that, yes, web browser sucks, so the best we can do is give you ability to kill a part of it when it misbehaves.

It was done for both reasons. Here's the Google Chrome comic book talking about it:

https://www.google.com/googlebooks/chrome/small_04.html

Another benefit they cite is reduced memory fragmentation. Because each tab lives in its own memory space, when the tab closes the OS can reclaim all of its memory. Presumably you'd still get framentation, but the OS is probably better able to handle that long term than jemalloc. Clever!

The points didn’t age well, but there’s a kernel of truth in there: none of those things will ever work 100%, so if you’re trying to really lock things down you need defense in depth, which was also not a new security concept in 2005, but it was one we were, as an industry, less sophisticated about.

"Defence in depth" is a term with obvious military origins.

You have a relatively thin front-line of defence, with orders to fall back if they are in danger of being overrun. Then you have a very strong second line, manned with assault troops. As the first line falls back, the second line counterattacks.

This strategy was developed by the Germans in WWII, and adopted by the Russians.

I disapprove of it's use in computer security. There, it means something different; it means basically having multiple lines of defence, without any notion of counterattack.

The future is probably a two tiered system like what Apple is showing with Lockdown Mode. Normal users get the full speed fully functional system. And those who are at risk of being targeted use a locked down system with less convenience features but more security.

Along with better languages and tooling ruling out entire classes of exploits.

Reply on news.ycombinator.com