Live data from Hacker News

Some thoughts on security after ten years of Qmail 1.0

blog.acolyer.org

61–70 of 123 posts

Re: Some thoughts on security after ten years of Qmail 1.0

#61
post #4

As we cast about trying to figure out ways to make software more secure or reliable, please remember that in other engineering fields (civil, chemical, mechanical, etc.) prioritizing safety and reliability is a _solved problem_. (1996) https://www.fastcompany.com/28121/they-write-right-stuff > It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program — each…

> in other engineering fields (civil, chemical, mechanical, etc.) prioritizing safety and reliability is a _solved problem_. One big difference between those and programming is that there (outside of military, physical security, and few other exceptions) there are no active adversaries for your project. You design a X that will serve a defined purpose. You design for some parameters (known wind speeds or local natura…

> You don't normally design with someone actively trying to destroy your building in mind.

You do, actually. When designing a building, one considers many "attacks" it can be subject to, depending on the geography and demography of the site: what are the precipitation patterns like, what is the situation WRT sysmical activity, how is the soil, what is beneath, what is the crime rate in the area, what kind of animals live there, where does the wind tend to come from, how much sunlight is received, etc. etc., about all of these questions are in one way or another is relevant to security of a building, and you have to consider each and every one of them, and design accordingly. You don't design against destruction because that's hardly possible, there isn't much you can do to mitigate someone bombing a building or attacking with heavy machines. Think of that as analogous to using the ME in an Intel CPU.

Re: Some thoughts on security after ten years of Qmail 1.0

#62
post #28
post #4

As we cast about trying to figure out ways to make software more secure or reliable, please remember that in other engineering fields (civil, chemical, mechanical, etc.) prioritizing safety and reliability is a _solved problem_. (1996) https://www.fastcompany.com/28121/they-write-right-stuff > It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program — each…

I read an article many many years ago explaining why software engineering can't be compared to mechanical engineering. I can't find it now, but one of its points of comparison was: if a nut isn't tightened enough on a bridge, you can tighten it a bit more -- turn the nut 3 or maybe 6 millimeters more. In software engineering, if you tighten the nut only 3 millimeters instead of 6, one of the bridge's endpoints now en…

Yeah, I've completely stopped buying this idea that software engineers just need to do what all the other engineers do to improve. Let me know when someone engineers an n-dimensional bridge.

For that matter, let me know when your engineers have built something as complex as the AWS infrastructure, by which I mean, every single service they offer, by information content (something like Kolmogorov complexity). There are some disciplines like power management that certainly have some very large and impressive things that I don't wish to diminish, but the idea that software engineering needs to go learn from all the other engineers is an idea stuck in a very 1970s view of what a "large project" looks like.

I am abundantly confident that if you took the amount of engineering done to build something like the Golden Gate bridge today, then took all those man-hours and saw how much software you could get for the same amount, that you'd be surprised how small the result is. Not that it wouldn't be a good chunk of hours to play with, and it would be much larger than many phone apps or web sites, but if you stack it up to something like a browser or a usable OS kernel I'm pretty sure you'd find that the very visually-imposing bridge is actually orders of magnitude, plural, simpler. I say this not because I don't respect civil engineers, but because I also respect just how quickly big computer projects can chew through the man-centuries. No bridges would get built if each one individually required engineering effort commensurate to a new web browser.

It's past time for programmers to get over their inferiority complex. A sober look at what the programming world does vs the other engineering fields shows that all things considered, we're doing pretty well. Still a huge amount of room for improvement, but we're not doing so badly that we need to go running off to other completely different disciplines to drag in irrelevant, if not actively harmful, practices that are unconnected to the problems we face.

Re: Some thoughts on security after ten years of Qmail 1.0

#63
post #61

Earlier quoted context omitted.

> in other engineering fields (civil, chemical, mechanical, etc.) prioritizing safety and reliability is a _solved problem_. One big difference between those and programming is that there (outside of military, physical security, and few other exceptions) there are no active adversaries for your project. You design a X that will serve a defined purpose. You design for some parameters (known wind speeds or local natura…

> You don't normally design with someone actively trying to destroy your building in mind. You do, actually. When designing a building, one considers many "attacks" it can be subject to, depending on the geography and demography of the site: what are the precipitation patterns like, what is the situation WRT sysmical activity, how is the soil, what is beneath, what is the crime rate in the area, what kind of animals…

'When designing a building, one considers many "attacks" it can be subject to'

Your use of scare quotes is appropriate, because there is a qualitative difference between intelligently-driven and unintelligent attacks. Not to mention the intelligently-driven attacks when the attackers are manifestly more intelligent and skilled than the defenders! If computer security experts didn't have to worry about intelligent attackers, computer security would be very nearly a solved problem.

Re: Some thoughts on security after ten years of Qmail 1.0

#64
post #34
post #20

Earlier quoted context omitted.

Bullshit. Justify the recent Hawaii emergency notification in the context of an airliner. You can't because we would never tolerate that kind of unreliability in our transportation infrastructure. Twitter does what it says on the tin. That doesn't mean software engineering is a mature discipline.

In a sense, software engineering is quite mature. It's probably matured a lot faster than most other engineering branches. We know about static analysis, fuzzing, unit testing, integration testing, functional testing, Continuous Integration/Deployment/Delivery, etc., etc. It's just that maturity costs a lot of money. 95% of the software produced just doesn't need that and the client can't even afford it.

Most people also cannot afford to buy cars or houses in one go, yet regulations don't get ignored because of them.

Re: Some thoughts on security after ten years of Qmail 1.0

#65

Earlier quoted context omitted.

If you're building houses, and your walls are a "few centimeters" off from straight, you'll get a real asswhoopin'. Especially if you're building something with more than one story, and you expect people to actually pay for it.

I’ve never found a perfect 90 degree angle in any house, and I’ve built portions of quite a few. Wood expands and contracts with the seasons.

Which also makes it a really silly choice for actual construction.

Brick and concrete make a lot more sense.

Re: Some thoughts on security after ten years of Qmail 1.0

#66
post #64
post #34

Earlier quoted context omitted.

In a sense, software engineering is quite mature. It's probably matured a lot faster than most other engineering branches. We know about static analysis, fuzzing, unit testing, integration testing, functional testing, Continuous Integration/Deployment/Delivery, etc., etc. It's just that maturity costs a lot of money. 95% of the software produced just doesn't need that and the client can't even afford it.

Most people also cannot afford to buy cars or houses in one go, yet regulations don't get ignored because of them.

There is almost no way we can compare cars and houses with the average CRUD software, in terms of damage they can do to a person.

More than that, even in the case where damage does happen, most people would rate physical damage higher than non-physical damage, for example monetary loss.

Re: Some thoughts on security after ten years of Qmail 1.0

#67

Earlier quoted context omitted.

If you're building houses, and your walls are a "few centimeters" off from straight, you'll get a real asswhoopin'. Especially if you're building something with more than one story, and you expect people to actually pay for it.

I’ve never found a perfect 90 degree angle in any house, and I’ve built portions of quite a few. Wood expands and contracts with the seasons.

Yeah, "a few centimeters" is a lot, but under 1/4 inch is close enough for most residential framing. Windows and doors are always shimmed to fit the rough framing for this reason.

Re: Some thoughts on security after ten years of Qmail 1.0

#68
post #56
post #54

Earlier quoted context omitted.

Ridiculous example: Qmail refused CRLF e-mails because the headers couldn't be read. It only accepted LF e-mails. In practice, this meant an e-mail client like Outlook did not work. It was solved by a very small fix with a few lines of C, but the patch I found did not apply cleanly either because it was for an older version or because of other patches, so I had to port it. This makes something like autoconf where you…

You have that backwards. Qmail rejected emails with bare LF because it was in violation of the email spec. https://cr.yp.to/docs/smtplf.html

It's still a real issue though: As an ISP you can't run a mail server that doesn't accept mails from the one client that's most used among your customers.

Yes. Outlook isn't conforming to the spec, but it's also being actively used and even if you could put pressure on Microsoft to fix it (good luck doing that back in the early 00s), you can't possibly force all your customers to update.

Now you have three options:

1. you switch MTA to one that can deal with the non-conforming clients.

2. you add a proxy server that interfaces between the non-conforming clients and your MTA

3. you patch your MTA

Unfortunately, because of qmail's good reputation ("hey! we're running qmail that never had security issues!") and because of the lack of abilities of your run of the mill ISP to write a scaling SMTP proxy, what people have traditionally have done is option 3.

What they forget about option 3 is that the one big advantage of that solution ("hey! we're running qmail") isn't valid any more because you're not exactly running qmail any more. You're running qmail plus some additional patches that actually touch the public interface of your MTA and are thus exposed to the network. To unauthenticated users.

So IMHO, they should have gone with option 1) or, nowadays where it's easier to write a well-scaling SMTP proxy thanks to the raise of asynchronous event based communication, option 2, but you'd better be sure you're not introducing security flaws in your reverse proxy.

Re: Some thoughts on security after ten years of Qmail 1.0

#69
post #68
post #56

Earlier quoted context omitted.

You have that backwards. Qmail rejected emails with bare LF because it was in violation of the email spec. https://cr.yp.to/docs/smtplf.html

It's still a real issue though: As an ISP you can't run a mail server that doesn't accept mails from the one client that's most used among your customers. Yes. Outlook isn't conforming to the spec, but it's also being actively used and even if you could put pressure on Microsoft to fix it (good luck doing that back in the early 00s), you can't possibly force all your customers to update. Now you have three options: 1…

It's not a real issue because those clients don't exist anymore.

Nearly twenty years ago when they did, (4) I could use fixcrio (which is hardly a proxy server): I simply ran it one of the ports that accepted mail from MUAs directly.

Re: Some thoughts on security after ten years of Qmail 1.0

#70

Earlier quoted context omitted.

I’ve never found a perfect 90 degree angle in any house, and I’ve built portions of quite a few. Wood expands and contracts with the seasons.

Which also makes it a really silly choice for actual construction. Brick and concrete make a lot more sense.

Expanding and contracting is good. Steel also expands and contracts. Bricks and un-reinforced concrete crack and crumble.
Post reply on HN