Hm, sorry, that last comment might not have been very clear.
Local access is not physical access. It means having credentials as a user on the machine, and being able to use them. So for example, if you have a user account on a Mac in a different country, and you can SSH to it (or, say, use screen sharing to log in), then that is "local access", even if you're 10,000 miles away.
Many exploits can give you local access, but not admin privs. And many others can give you admin privs if you already have local access, but not the access. So often attacks will consist of using one exploit (or, sometimes, social engineering) to gain local access, and then another unrelated one to gain root (admin access). The sudo vulnerability gives you the second half of that chain.
Thankfully, I am just not important enough for anyone to want to physically access my Mac and hack it. Even if they did, nothing much to see here. Dissidents from places like Saudi Arabia, Iran or China might want to be more careful ...
Physical access is not required. You just need "local access". That means you need to be able to run code, or get a shell, and then you have root. It's one half of the holy grail- the other half is gaining non-privileged local access.
Of course with catalina and big sur things are more complicated because of the protected boot volume. So it's harder to be persistent. But not by much.
For most people what matters and is private to them is on their home folder, not on root anyway. If I guy is at my computer because he has my password he can get in everywhere, no touchID needed., just unlock a keychain.
Its a bit harder if he hasn't my password but even then he can get lots of information on me in my email, or notes. Nothing is locked, except the odd Note. I have passport photos and probably bank account details stored somewhere on the home folder.
Given how long these tools have been around (40+ years in some cases), how relatively simple the code is compared to modern software, and the fact that they're used in server environments, I'm very surprised they haven't been fully security audited by now.
They aren’t that simple. That’s the problem. They are written in unsafe languages like C and C++ where memory management was up to the code writer.
True. Though the problem in sudo is considerably more tricky than just a typical use-after-free or similar. Read the original post about the exploit.
Actually, it looks like this exploit takes advantage of vulnerabilities in C stdin processing. This underlying functionality is traceable all the way back to the earliest version of C that most C programmers learned from their trusty and very thin K&R language reference. Over the decades more and more functionality has been layered on top of these “primitive” functions, including the fundamental operation of web servers.
The real issue imho is that while a lot of underlying legacy code has a long and time tested verification of proper functionality, the code was not designed and has not been updated with sufficient consideration for the existential security threats that have evolved over time.
Yes, so something like this:
char filename[512];
...
filename = getPath(....)
This works until there is a change in the operating system to allow filenames longer than 512, then it is a vulnerability at worst or a crash.
Probably something like this happened for the stdln . I don't think these old codebases can be easily updated to handle reference counting.
Given how long these tools have been around (40+ years in some cases), how relatively simple the code is compared to modern software, and the fact that they're used in server environments, I'm very surprised they haven't been fully security audited by now.
They aren’t that simple. That’s the problem. They are written in unsafe languages like C and C++ where memory management was up to the code writer.
True. Though the problem in sudo is considerably more tricky than just a typical use-after-free or similar. Read the original post about the exploit.
Actually, it looks like this exploit takes advantage of vulnerabilities in C stdin processing. This underlying functionality is traceable all the way back to the earliest version of C that most C programmers learned from their trusty and very thin K&R language reference. Over the decades more and more functionality has been layered on top of these “primitive” functions, including the fundamental operation of web servers.
The real issue imho is that while a lot of underlying legacy code has a long and time tested verification of proper functionality, the code was not designed and has not been updated with sufficient consideration for the existential security threats that have evolved over time.
Yes, so something like this:
char filename[512];
...
filename = getPath(....)
This works until there is a change in the operating system to allow filenames longer than 512, then it is a vulnerability at worst or a crash.
Probably something like this happened for the stdln . I don't think these old codebases can be easily updated to handle reference counting.
No, these old UNIX tools don't use C++ since it was only in its inception when they were created. Not to mention the extra memory overhead made it a non-starter at that time.
As for your example, that's a buffer overflow attack vector. It's pretty much the top item on the list for security audits: checking all sources of input for possible buffer overflows (or invalid data which could lead to a buffer overflow when parsing it).
As for memory management and an ownership model, see the system Apple uses in their low level C APIs (Core Foundation).
Given how long these tools have been around (40+ years in some cases), how relatively simple the code is compared to modern software, and the fact that they're used in server environments, I'm very surprised they haven't been fully security audited by now.
sudo is not at all simple, and it has reached the level of complexity where it's basically impossible to confidently reason about it. The OpenBSD team made something simpler (doas) a while ago. Maybe this is the kick people need to finally adopt it more broadly.
I agree that Apple should be paying attention to what the OpenBSD community is doing. That said, every developer I've ever met thinks that recreating the world in their own image is better than trying to fix what already exists. Right up until the point where they no longer have the time/desire to maintain the world they created, and the next developer who comes along has the same attitude. Given that it's no small undertaking to integrate new, low level tools, I'm sure Apple (and others) don't want to spend the effort to change, just to have to change again. They'll wait for a level of maturity, maintenance, and acceptance before changing.
TedU is great at fixing things which already exist, and when he decides it's time to start over, I'm inclined to believe him. It's like if John Carmack says you really should use a new game engine.
I'm not swayed by the cult of personality or seniority, only by rationally debated arguments with supporting evidence.
The sudoers manpage alone is 2871 lines long. It opens with a "quick guide to Extended Backus-Naur Form", which is a language for defining the grammar of formal languages. That's gratuitously complicated. sudo's source tree has 374 C-language files in it right now.
Yeah, I remember learning Backus-Naur Form when I was first learning programming in C. It has a history in linguistics which goes back much further than computing science as a way to describe the structure of languages. I actually think that part of the history of computing science is far more interesting than modern day. Where people with backgrounds in mathematics, linguistics, philosophy, cognitive science, etc were also involved in the development of technology. Seeing the bigger picture of how technology fits with humanity, rather than just being fixated on the machines or the code running them. Pretty much all modern technology is based on the ideas developed from 1930 to 1970.
But anyway, I'm digressing here a bit. Just wanted to make a point about being too fixated on the particulars of your situation and not seeing the bigger picture. I don't know for certain, but based on similar experiences with small, well-designed codebases turning into bloated nightmares, my guess is that sudo started out as a well-designed tool for a simple purpose, and was adapted to more and more specialized situations until it turned into the mess it is today. My approach would be to try to break it up into a few different tools which cover all of those use cases, but in a more manageable way. Kind of like what Apple did with iTunes. The problem with completely starting from scratch is that you'll lose all of those use cases. The tool will work fine in your particular situation, but to expect it to be widely adopted requires seeing the bigger picture of what the tool you're replacing was doing for everyone else.
Given how long these tools have been around (40+ years in some cases), how relatively simple the code is compared to modern software, and the fact that they're used in server environments, I'm very surprised they haven't been fully security audited by now.
sudo is not at all simple, and it has reached the level of complexity where it's basically impossible to confidently reason about it. The OpenBSD team made something simpler (doas) a while ago. Maybe this is the kick people need to finally adopt it more broadly.
I agree that Apple should be paying attention to what the OpenBSD community is doing. That said, every developer I've ever met thinks that recreating the world in their own image is better than trying to fix what already exists. Right up until the point where they no longer have the time/desire to maintain the world they created, and the next developer who comes along has the same attitude. Given that it's no small undertaking to integrate new, low level tools, I'm sure Apple (and others) don't want to spend the effort to change, just to have to change again. They'll wait for a level of maturity, maintenance, and acceptance before changing.
TedU is great at fixing things which already exist, and when he decides it's time to start over, I'm inclined to believe him. It's like if John Carmack says you really should use a new game engine.
I'm not swayed by the cult of personality or seniority, only by rationally debated arguments with supporting evidence.
And with that, I discard your opinion, because you clearly don't know what you're talking about, or either of the people I mentioned.
Given how long these tools have been around (40+ years in some cases), how relatively simple the code is compared to modern software, and the fact that they're used in server environments, I'm very surprised they haven't been fully security audited by now.
They aren’t that simple. That’s the problem. They are written in unsafe languages like C and C++ where memory management was up to the code writer.
True. Though the problem in sudo is considerably more tricky than just a typical use-after-free or similar. Read the original post about the exploit.
Actually, it looks like this exploit takes advantage of vulnerabilities in C stdin processing. This underlying functionality is traceable all the way back to the earliest version of C that most C programmers learned from their trusty and very thin K&R language reference. Over the decades more and more functionality has been layered on top of these “primitive” functions, including the fundamental operation of web servers.
The real issue imho is that while a lot of underlying legacy code has a long and time tested verification of proper functionality, the code was not designed and has not been updated with sufficient consideration for the existential security threats that have evolved over time.
Yes, so something like this:
char filename[512];
...
filename = getPath(....)
This works until there is a change in the operating system to allow filenames longer than 512, then it is a vulnerability at worst or a crash.
Probably something like this happened for the stdln . I don't think these old codebases can be easily updated to handle reference counting.
No, these old UNIX tools don't use C++ since it was only in its inception when they were created. Not to mention the extra memory overhead made it a non-starter at that time.
As for your example, that's a buffer overflow attack vector. It's pretty much the top item on the list for security audits: checking all sources of input for possible buffer overflows (or invalid data which could lead to a buffer overflow when parsing it).
As for memory management and an ownership model, see the system Apple uses in their low level C APIs (Core Foundation).
That was C, not C++ although it would work in C++. The point about the audit tool is that that buffer wouldn't be an overflow until the returning call started to return a value bigger than 512. To make the audit work they would have to know what all calls, system or not, had changed. That can't be totally automatic.
Given how long these tools have been around (40+ years in some cases), how relatively simple the code is compared to modern software, and the fact that they're used in server environments, I'm very surprised they haven't been fully security audited by now.
They aren’t that simple. That’s the problem. They are written in unsafe languages like C and C++ where memory management was up to the code writer.
True. Though the problem in sudo is considerably more tricky than just a typical use-after-free or similar. Read the original post about the exploit.
Actually, it looks like this exploit takes advantage of vulnerabilities in C stdin processing. This underlying functionality is traceable all the way back to the earliest version of C that most C programmers learned from their trusty and very thin K&R language reference. Over the decades more and more functionality has been layered on top of these “primitive” functions, including the fundamental operation of web servers.
The real issue imho is that while a lot of underlying legacy code has a long and time tested verification of proper functionality, the code was not designed and has not been updated with sufficient consideration for the existential security threats that have evolved over time.
Yes, so something like this:
char filename[512];
...
filename = getPath(....)
This works until there is a change in the operating system to allow filenames longer than 512, then it is a vulnerability at worst or a crash.
Probably something like this happened for the stdln . I don't think these old codebases can be easily updated to handle reference counting.
No, these old UNIX tools don't use C++ since it was only in its inception when they were created. Not to mention the extra memory overhead made it a non-starter at that time.
As for your example, that's a buffer overflow attack vector. It's pretty much the top item on the list for security audits: checking all sources of input for possible buffer overflows (or invalid data which could lead to a buffer overflow when parsing it).
As for memory management and an ownership model, see the system Apple uses in their low level C APIs (Core Foundation).
That was C, not C++ although it would work in C++. The point about the audit tool is that that buffer wouldn't be an overflow until the returning call started to return a value bigger than 512. To make the audit work they would have to know what all calls, system or not, had changed. That can't be totally automatic.
Exactly. Not all audits are created equal. I'm sure sudo has gone through security audits dozens (hundreds?) of times before now.
Comments
Its a bit harder if he hasn't my password but even then he can get lots of information on me in my email, or notes. Nothing is locked, except the odd Note. I have passport photos and probably bank account details stored somewhere on the home folder.
Yes, so something like this:
This works until there is a change in the operating system to allow filenames longer than 512, then it is a vulnerability at worst or a crash. Probably something like this happened for the stdln . I don't think these old codebases can be easily updated to handle reference counting.
As for your example, that's a buffer overflow attack vector. It's pretty much the top item on the list for security audits: checking all sources of input for possible buffer overflows (or invalid data which could lead to a buffer overflow when parsing it).
As for memory management and an ownership model, see the system Apple uses in their low level C APIs (Core Foundation).
Yeah, I remember learning Backus-Naur Form when I was first learning programming in C. It has a history in linguistics which goes back much further than computing science as a way to describe the structure of languages. I actually think that part of the history of computing science is far more interesting than modern day. Where people with backgrounds in mathematics, linguistics, philosophy, cognitive science, etc were also involved in the development of technology. Seeing the bigger picture of how technology fits with humanity, rather than just being fixated on the machines or the code running them. Pretty much all modern technology is based on the ideas developed from 1930 to 1970.
But anyway, I'm digressing here a bit. Just wanted to make a point about being too fixated on the particulars of your situation and not seeing the bigger picture. I don't know for certain, but based on similar experiences with small, well-designed codebases turning into bloated nightmares, my guess is that sudo started out as a well-designed tool for a simple purpose, and was adapted to more and more specialized situations until it turned into the mess it is today. My approach would be to try to break it up into a few different tools which cover all of those use cases, but in a more manageable way. Kind of like what Apple did with iTunes. The problem with completely starting from scratch is that you'll lose all of those use cases. The tool will work fine in your particular situation, but to expect it to be widely adopted requires seeing the bigger picture of what the tool you're replacing was doing for everyone else.