18

I am having a discussion with friends and my point is that the older a feature-frozen operating system is, the fewer security bugs are left unpatched and therefore the cost for the company to fix them decreases with age.

My assumption is: there are a finite number of bugs in a code which is not changed except for fixing bugs. The more get fixed, the fewer there are.

With "feature frozen" I mean an operating system which receives no more feature updates, but only security updates. For example Windows 7, from when feature updates ended 7 years ago until when security updates ended 2 years ago, or Windows 8.1 now, since feature updates ended 4 years ago and security updates will continue for another 11 months. I based these examples on https://endoflife.date/windows

This does not mean that fixing one bug won't introduce another one, but that in general, fewer bugs are introduced with bugfixes than are fixed.

Is my assumption correct? Is the frequency of (still open) vulnerabilities decreasing with age of a software, in particular of an operating system, from the moment it is feature-frozen until the end of security support?

I found for example the website CVEdetails on Windows 7 but I cannot manage to restrict the search to unpatched bugs. I think it lists the frequency of new security bugs.

Not part of the question, but to explain why I got thinking about what I asked above:

Software companies provide a software, and in my opinion they should fix any vulnerability which gets discovered as long as customers are allowed to run the system, or they should kill it, like Sonos did with their unsupported speakers (for an operating system, it would not kill the machine but refuse to run past its extended support expiration date). Therefore I was wondering whether the older the system, the fewer vulnerabilities are discovered, and the lower the costs incurred in this endless security support. Of course not supporting it is cheaper, but that's not "right" according to my point of view.

FarO
  • 323
  • 2
  • 9
  • 11
    You can't take the number of published CVEs to measure the "security of an OS". For example the CVEs published affecting Windows 7 were as far as I know mostly CVEs that were found for newer Windows versions but also affecting Windows 7. So you can assume that a majority of security researcher do no longer actively search for problems in Windows 7 thus the number of found problems decreases (not because the OS is more secure). – Robert Feb 01 '22 at 10:06
  • 1
    @Robert well we cannot judge based on what we don't know: we cannot expect companies to fix.. yet undiscovered bugs. My first paragraph clarifies my position: the costs for a company to fix known security issues decreases with age (even assuming there is no end to "security support") because fewer and fewer bugs affecting a system are found. Sure some affect multiple versions, but then fixing them in an older OS is likely very cheap, since the fix can be deployed for multiple versions. – FarO Feb 01 '22 at 10:46
  • 1
    Maintaining n platforms is cheaper than maintaining n+1 platforms. So it may be cheap, but it incurs a non-zero cost. – vidarlo Feb 01 '22 at 10:52
  • 1
    @FarO What you say may be valid for regular bugs, but vulnerabilities are usually only found if someone actively searches for it, so they the are totally different. History tells us that even systems used for 10 or even 20 years can still contains severe security problems. They have not been found yet because no-one has searched for them. – Robert Feb 01 '22 at 11:07
  • 1
    It was not related to the specific point of my question, but here the whole discussion: software companies provide a software, and in my opinion they should fix any vulnerability which gets discovered as long as customers are allowed to run the system, or they should kill it, like Sonos did with their unsupported speakers. To support my view is that probably the older the system, the fewer vulnerabilities are discovered, and the costs incurred in this endless security support are decreasing. Of course not supporting it is cheaper, but that's not my point of view. But we are chatting now... – FarO Feb 01 '22 at 11:25
  • 6
    "they should fix any vulnerability which gets discovered as long as customers are allowed to run the system, or they should kill it" -- whoa, this is a totally different issue. Microsoft announces that they are not going to support it anymore, provide years of warning, and provide an alternative. To forcibly block people from using one of the most-used products on the planet would be a much bigger issue. – schroeder Feb 01 '22 at 11:35
  • 2
    @FarO: I think one has to distinguish between security issues newly introduced and security issues fundamental to the design of the system (like running printer drivers or font-reendering with high privileges - which regularly caused problems). Newly introduced issues get fewer since fewer code gets changed. But fundamental design issues will usually not get fixed at all because the costs of implementing and of potentially breaking something are too high. – Steffen Ullrich Feb 01 '22 at 11:52
  • 2
    @FarO: "What is the frequency of open security bugs ... fewer security bugs are left unpatched"* - If you ask about the absolute number of open bugs then the term frequency is wrong. You can ask about how frequent new issues occur or how frequent issues gets fixed - and both numbers are likely decrease in time for feature-frozen systems. But this does not necessarily mean that the number of remaining bugs gets zero - or even that less and less bugs remain. – Steffen Ullrich Feb 01 '22 at 11:58
  • 1
    Are protocol changes included as a "bug". Systems that support only SMB1 have issues that should be fixed but no CVE will ever be issued. – doneal24 Feb 01 '22 at 17:46
  • 1
    @doneal24 indeed the question is more complex than I thought. I would say that architecture issues do not count, but then which one is what? some are difficult to categorise – FarO Feb 01 '22 at 22:01
  • 1

    it would not kill the machine but refuse to run past its extended support expiration date

    Emphatically no. That would be a gross violation of the rights of the users.

     – preferred_anon Feb 02 '22 at 11:57
  • 1
    There are two major problems with your reasoning: (1) Windows’s publisher might keep its code locked up so that no one else can offer support, but not all operating systems are like that. If others can offer support, there is no reason to kill the system. (2) Even if it is true that older systems have fewer bugs, that does not mean the bugs are easier to fix. In fact, they would probably be harder to fix. Firstly, if they were easy to fix, they would already have been fixed. Secondly, the code is old, and different to the new code everyone is used to, so it is hard to work on at all. – Brian Drake Feb 03 '22 at 07:52
  • @BrianDrake I think you should post it as answer. – FarO Feb 03 '22 at 09:26
  • The problem with developing a piece of software and only removing bugs, never adding features, is that eventually you'll end up with a piece of code that has (hopefully) no bugs and (definitely) no users. And you're also assuming that bugs aren't introduced by an underlying library... – Shadur-don't-feed-the-AI Feb 03 '22 at 17:27
  • 2
    There is indeed a finite number of bugs but it is huge. For all practical purposes the millions of LOC comprising modern operating systems can be considered an infinite source of bugs. – Peter - Reinstate Monica Feb 03 '22 at 18:21

4 Answers4

30

Interesting theory but...

Even in open-source code, serious bugs can go unnoticed for a very long time (think Log4j), because nobody had the time or inclination to analyze the code. Probably, a three-letter agency or a 0-day merchant knew but did not disclose what they knew, so the public at large was left in the dark and vulnerable.

It's true that old, proven software tends to become more reliable over time, it can have fewer bugs, but the bugs can still be very serious. The problem is not the number of bugs, but their severity.

Operating systems contain third-party code too, so they are routinely shipped with flawed dependencies, that are time bombs waiting to explode. Another recent example is the polkit vulnerability affecting Linux systems. Not to mention closed-source binaries such as drivers or firmware blobs. Note that the polkit vulnerability is a privilege escalation, you have to be a local user to exploit it, so it is less serious than the Log4j vulnerability (which can be triggered remotely by an unauthenticated user).

But a "feature-frozen" OS is dead by definition. To stay relevant an OS must keep adding features, just to keep up with new hardware. Over time the number of lines of code tends to increase, not decrease. For a modern OS, it is expressed in millions of lines of code. For instance:

The Linux kernel has around 27.8 million lines of code in its Git repository, up from 26.1 million a year ago, while systemd now has nearly 1.3 million lines of code, according to GitHub stats analysed by Michael Larabel at Phoronix.

Source: Linux in 2020: 27.8 million lines of code in the kernel, 1.3 million in systemd

And complexity is the enemy of security. Generally speaking, the more complexity, the more there is potential for bugs. Software in general never gets "simplified", bloat is more like the norm. While it is possible that there are fewer bugs over time, I find that counter-intuitive.

Speaking of dead operating systems: OS/2 is still used at some places, even for crucial industrial processes. Example: The OS/2 Operating System Didn’t Die… It Went Underground.. But the environments tend to be quite specific and isolated.

I find it difficult to answer the question, you could look at CVE statistics but they only list the reported vulnerabilities. And many vulnerabilities are reported outside of "official" channels, sometimes disclosure takes place through Github, a tweet, or a post on a mail list.

But what matters is the severity, not the quantity.

The bottom line is that even sane code can be vulnerable because it depends on a larger ecosystem of dependencies. For example, many applications are still shipping with vulnerable and outdated DLLs. The problem is the packaging and the lack of upstream quality control. Very common problem in this industry.

I would make the case that the bugs that get fixed are the bugs that are visible, that is functional bugs that the users experience and can reproduce. They are easier to identify and report. The more serious bugs, the security vulnerabilities are not the most visible.

Kate
  • 7,937
  • 25
  • 27
  • 1
    For old unnoticed bugs: the recent pkexec bug, which has been there since 2009. Local privilege escalation, CVE rated at 7.8. https://www.whitesourcesoftware.com/resources/blog/polkit-pkexec-vulnerability-cve-2021-4034/ edit: wrote this comment before noticing you mention it. – jaskij Feb 02 '22 at 05:48
  • 2
    Isn't the assumption that adding drivers requires extending the kernel flawed in general? The current customer/server mainstream OS are monolithic and therefore embed driver code within the kernel, however that's not an intrinsic quality of kernels, it's just happenstance. A micro-kernel could still be extended with user-space drivers, for example, possibly delivered as 3rd-party applications: this would extend the "lifetime" of the system without introducing vulnerabilities in the kernel/OS itself. – Matthieu M. Feb 02 '22 at 10:33
  • 5
    I'd also add that bugs are not singular things. A bug may not be able to be found in one environment, but when the environment changes, the bug may be findable/exploitable. – Kevin McKenzie Feb 02 '22 at 14:44
  • @MatthieuM.: Isn't Windows NT a microkernel system? – Vikki Feb 02 '22 at 16:59
  • 2
    @Vikki It was originally intended to be a microkernel, but was switched to hybrid for performance reasons. It does allow for user mode drivers though. – nobody Feb 02 '22 at 17:14
  • 2
    @Matthieu I don't see what microkernels have to do with user-space drivers. All the successful mainstream OSes (not a single microkernel to be found) have no problems providing user-space drivers for many things. You can also (and it is the standard) provide kernel-level drivers separately or load whole extra modules. But there are some things you cannot do in a user-mode driver. I'd be very impressed if you could for example do ACPI and other power saving options in user-mode, not to speak of advanced scheduling to get good performance. – Voo Feb 02 '22 at 20:39
  • @Voo: Microkernels are the extreme example, hence why I used them to illustrate the idea. The crux of the argument is that I do not necessarily see a causality effect between "feature frozen kernel" and "feature frozen OS", nor between "feature frozen OS" and "irrelevance". It's a theoretical argument, perhaps, since the mainstream OSes are all in active development, but the question was rather theoretic it seems to me. – Matthieu M. Feb 03 '22 at 08:15
13

Apart from all the points raised by others, another thing to consider is the fact that a feature frozen will not receive newly implemented security features either. While security features don't patch bugs themselves, they make exploiting the bugs either more difficult, or in some cases, impossible. Which means that while older OSes may have less bugs, more of those bugs may be exploitable.

For example, Windows Defender Exploit Guard, which is an important set of mitigations for security vulnerabilities, is only available on Windows 10 (older versions can use EMET, but that reached end of support in 2018). Kernel Data Protection is another virtualization-based security feature that was added in Windows 10.

nobody
  • 11,555
  • 2
  • 43
  • 60
  • 4
    Aaand then there's stuff like security protocols, like how TLS 1.3 was only defined in 2018 so something that stopped having feature updates in 2015 wouldn't have it. Which may cause issues down the line if one wants to connect with it to the rest of the world. – ilkkachu Feb 02 '22 at 15:36
2

The assumption that there are a fixed number of bugs, that must be found, and can therefore only reduce (making it safer), may be true in theory, but is deeply flawed in a practical sense. That's the basic problem.

What we care about

A modern OS has tens of millions of lines of code, in some cases hundreds of millions. We don't care about bugs really, its more helpful and instructive to care about exploitable vulnerabilities - which can include deliberate design choices, dependencies, and many other means by which a system can be compromised.

For a non-OS example of the difference, consider hacking of 2 factor authentication, by (1) socially engineering a persons mobile phone provider, to persuade them to issue a new SIM or maybe change the SIM email address. We now click "2FA login", and use the "stolen" SIM access to get the 2FA login code. Or perhaps (2) we find their password in a hack of some third party site and its the same as their email password so we issue a password reset then use their email account, to get a replacement logon issued ("Forgot your password?"). Or maybe (3) they lost their laptop with SSH login certificate included and it takes them a day to notice. Or (5) the encryption schema used for something was secure in fact but evolving research means its no longer secure. Or (5) hardware vulnerabilities exist too (DMA via FireWire, Bad Maid USB, you name it).

The point is that the 2FA or password reset or SSH login feature may be bug free, but a third party vulnerability let them hack. There's no "fixed number" of issues, and not all exploitable weaknesses are due to OS bugs. Who's to say what else could have been used?

So we can't even consider just the OS, or a concept of a static number of bugs. We have to consider the universe of things it may depend on, or evolving outside capabilities - things we maybe never considered until many years later. After all, SMS hacks weren't considered until a while after SMS existed. We have to consider the evolving landscape of exploits on the OS, or vulnerabilities.

We also need to distinguish between bugs, to be fixed, and new threats, to be countered. As some of these examples show, a new threat can arise, that didn't exist before. They may also reflect an issue that isn't really fair to classify as a bug in the system to be fixed, so much as a new threat opening due to external context changes that must be countered.

Theoretical vs practical risk

We also have to consider practical risk. Security is all about raising the barrier to misuse, there are rarely if ever perfectly secure systems, its always degrees of safety, "safer" not "absolutely safe".

Only in theory can this be disregarded. In all practical senses, we need to consider things like how much attention and use will this OS be getting, and what its used for, because more use => more interest to hack, more attention => more probing for new ways to hack it. Even an obscure OS may become of great interest if a use case is discovered to be government servers, nuclear or military control, manufacturing, energy, space, banks and financials, and R&D, or their back-end systems, to take some examples.

If a system is of great interest, then a lot of attention may go in to studying other systems connected to it, and their vulnerabilities too, as a stepping stone.

Your answer

For these reasons, you can rarely consider an OS, even one that's feature frozen except for bugfixes, as having a fixed number of bugs. It just doesn't happen that way, and won't help.

The OS is a dynamic environment, and interacts with its environment. So for all these reasons, you can't evaluate the scale or seriousness of exploits, without fixing it in a specific time, with specific outside focus, specific outside exploitable levers, specified hardware and hardware access, the criteria by which you measure and consider a system "secure" (barrier height), and so on.

Therefore an OS that was in fact secure (either in fact, or for your practical purposes) is quite capable of transitioning to being insecure...... not even because of an undiscovered bug requiring fixing, but because of some external factor requiring countering - and may well do so.

And that spells the end for your argument.

Stilez
  • 1,694
  • 9
  • 14
  • My argument was based on the idea that a company should fix what is sold as broken, if someone uses ways beyond the OS to attack me well it's not the manufacturer's fault. But thanks for the points you raised, they surely completed the overview together with the other answers – FarO Feb 03 '22 at 09:28
  • "Should fix what's sold as broken" - I don't think any company on earth can support indefinite updates for indefinite time, unpaid. After all, some systems using say XP embedded, OS/2 or similar from decades ago are still used. The question asked was more, is list of severe bugs a fixed thing that only goes down as bugs get found and fixed, and for the reasons given my answer both theoretically and in a practical threat sense, is sorry, clear "no". – Stilez Feb 03 '22 at 10:42
0

A bug is not a problem if nobody knows about it.

So, a new operating system like Windows 11 probably has tons of security holes, but it is OK as long as they are unknown.

Unfortunately, people will stumble across these bugs occasionally, either by disassembling the code or noticing some odd behaviour.

On a living OS, maintained by an active company like Microsoft, bugs get fixed pretty quickly once the company notices them. And fixes gets distributed to the users.

A criminal discovering a bug will generally only be able to use to for a very short time before it is closed. They can plan things and time their attack for the best/worst possible time, but it will still be a limited loss.

Now, compare this to Windows 7. Yes there are fewer bugs. But what happens when a new one is discovered? Microsoft basically says "Windows 7 is obsolete. You are on your own." The bug stays.

A criminal discovering a bug in Windows 7 would be able to exploit it forever. Well, at least a couple of decades until the last Windows 7 machine dies.

Stig Hemmer
  • 2,433
  • 11
  • 14