5 ms·

We're in 2023, and I'm still reading about pieces of software that can be exploited because of poor memory management (either unexpected reads, unexpected write

We're in 2023, and I'm still reading about pieces of software that can be exploited because of poor memory management (either unexpected reads, unexpected writes, or incorrect deallocation). When I started diving into memory issues two decades ago, the younger version of me really thought that, 20 years down the line, we would have figured out better ways to deal with memory other than those buggy malloc, free, sprintf and strcat. Guess what? We have! But way too much C/C++ code is still around. The X window system is 40 years old, some parts of its code literally stand on toothpicks and there's no one left around who still understands them, security flaws keep popping up once every 1-2 months, but it still powers nearly the entirity of the all the UIs that run on a UNIX - based system. Isn't that just insane?

quotemstr 4y ago
Too many people think they can write memory safe code when they can't, and they can't because they're human beings, and humans cannot write correct C. Then, when you point out that programs written in some languages are immune to entire classes of vulnerability, these people write things like this: > Memory safeness is just an illusion We're not going to make any progress as an industry until we stop indulging people who think C is cool.
- blacklight 4y ago
  I'm not saying that it's impossible to break things in Rust/Go/Dart. Im saying that it's several orders of magnitude more difficult. Bugs like these show that, no matter your level of experience in C/C++, you ALWAYS have a high chance of messing things up on memory access, because there are so many things you have to keep in mind while writing your code - and often these bugs are also very difficult to spot. We need to favour languages that don't make things perfect (there's no such thing), but that at least make it much harder for things to break. Like Stroustrup said, we need guns that make it harder to shoot your own leg.
  - pjmlp 4y ago
    Hence why the industry needs a little legal help push, just like when dealing with hazardous chemicals and sharp cutting tools. Thankfully it is starting to take place.
- asveikau 4y ago
  It is an illusion, in the sense that memory doesn't actually work "safely", and safety needs to be built from lower level primitives. Mind you, being an illusion is not criticism, and doesn't make it less of a good idea. There's people that believe all perception is illusion. Do they stop perceiving?
  - pjmlp 4y ago
    Not it isn't, dealing with chemicals and sharp tools is hazardous, hence why there are laws in place about work practices that must be obeyed. High integrity computing already has them, we just need a little push to apply them everywhere with liability for non compliance.
    - asveikau 4y ago
      The laws are not a property of the universe. They're a convention. Illusory. I'm not advocating not having laws, or saying they don't have value.
      - pjmlp 4y ago
        They look pretty physical for those affected by them.
asveikau 4y ago
> we would have figured out better ways to deal with memory other than those buggy malloc, free It's not malloc and free that are buggy here. Fundamentally, there is some layer of the system that needs to work like that. What people tend to advocate when they say they don't like this is keeping the size of code that needs to reason that way small and restricted. I.e. not writing an entire X server that way. But the allocator will still be there. Something needs to chop up the buffers in an unsafe way somewhere.
- blacklight 4y ago
  Of course, we all agree that on a low level the memory black magic still needs to happen. But the developer shouldn't be in charge of it - just like today's developers don't decide on which CPU register a certain variable should be stored, or how to overwrite the instruction pointer when performing a function call. I mean, of course there will always be cases where a developer needs to go this low - think of OS/firmware developers. But that doesn't apply to 99.9% of the developers out there. Most of the developers out there want a programming language where they can easily declare an array, append or remove stuff from it without breaking anything, and when there's no piece of code left that references that piece of memory then it should be deallocated - in such a way that should be invisible to the developer. So C/C++ nowadays cater to the 0.1% that needs to tinker with every bit of the memory, and those who love those languages want us to believe that their use-case is the same as the remaining 99.9%.
  - peoplefromibiza 4y ago
    > I mean, of course there will always be cases where a developer needs to go this low it made total sense when writing X11 though which made X11 last so long and still totally work we'll see in how many years Wayland will be rewritten because it's legacy, it still doesn't work everywhere after 15 years of trying hard.
semi-extrinsic 4y ago
If you think of code as infrastructure, it's not insane, it's the expected outcome. Bridges were built differently in the 1960s than they are today. We are not tearing down all the old bridges and building new ones, that would be crazy. Instead we need to spend enough time and money on maintenance of the old bridges, and replace them when that becomes the better option. When we fail to conduct proper maintenance, accidents happen, like Ponte Morandi.
- devwastaken 4y ago
  Old bridges are being replaced all the time. Modern bridges aren't built like the 1960's anymore, yet with code it's like we're still in 1990 when a new project starts.
- pjmlp 4y ago
  We are taking people to court that build broken bridges.
  - nix23 4y ago
    We aslo bring people to court who endanger/kill peoples per software-(bugs)... I also have seen many bridges where no responsibility can be assumed (especially in the mountains).
    - pjmlp 4y ago
      > We aslo bring people to court who endanger/kill peoples per software-(bugs)... Only in high integrity computing scenarios. All kinds of refunds and lawsuits from physical goods should apply to software as well. Regarding the bridges, just because "guilt died alone" as we say back home, doesn't mean we should disregard the bigger picture.
- timeon 4y ago
  Unlike software, civil engineering is subjected to regulations.
peoplefromibiza 4y ago
> We're in 2023, and I'm still reading about pieces of software that can be exploited because of poor memory management (either unexpected reads, unexpected writes, or incorrect deallocation). wait until 2123 when you will still read about them and Wayland will almost be ready. side note: can we please stop this nonsense whining around infrastructures? yes, infrastructures are old, they are old because they work, they work because they were carefully engineered and maintained. A bug in some infrastructure code is not the end of the World, it's, on the contrary, a sign of its vitality. Yes, roads still have holes in them, even though we invented them thousands years ago, it doesn't make them less useful. EDIT: rewriting X11 proved to be almost a failure, after 15 years, in 2023, on my laptop KDE/Wayland can't start the plasmashell, while X11 still rocks the boat without a glitch. This constant lamentation about "safe languages", that sounds like the sirens in The Odyssey, and the promotion of "rewrite it!" - in this case X11 (AGAIN!) - in some new shiny language of today like if 40 years totally make the difference between the past and the future, it's the most serious form of delusion I have ever witnessed in my whole life.
- blacklight 4y ago
  The problem is that, as IT technologies become older, there will be less and less people who can understand what's going on, debug and fix things. At that point, degradation becomes inevitable, and projects go in maintenance-only mode because adding new features is just too hard and risky. Have you wondered why the X.Org server still fails at doing simple things like inferring the DPI and supporting retina displays without extra configuration? Or why you need external window compositors? Have you ever tried to play with the X11 C API, just to land on cryptic documentation that hasn't been updated in 25 years? Or, worse, dive into the source code of the server, and find 40 years of workarounds that make you feel like taking one straw away will make the whole castle collapse? Note that the same also applies to other pieces of software (like xterm) that are way past their expiry date. Software should not get into this stage and still be massively used in production. We should avoid projects like X.Org from becoming the next COBOL.
  - peoplefromibiza 4y ago
    > At that point, degradation becomes inevitable, and projects go in maintenance-only mode because adding new features is just too hard and risky. I repeat it: Wayland is 15 years old and it's written in C. I'm waiting for a rewrite in Rust or whatever, so in 15 years I will still be using X11, because it's the only thing that works reliably across my devices, old and new. > Have you ever tried to play with the X11 C API yes, since 1996. > and find 40 years of workarounds that's called "SOLUTIONS" in professionals' World. The real World is full of edge cases, if your code is dealing with none of them, your solution is probably fragile. https://www.luckymethod.com/2013/03/the-big-redesign-in-the-sky/ https://www.luckymethod.com/2013/03/the-big-redesign-in-the-... > Software should not get into this stage and still be massively used in production > We should avoid projects like X.Org from becoming the next COBOL. That's the wrong way to look at it. We should ask ourselves: why COBOL is still in use after so long, while a JavaScript framework lasts 6 months and it's deprecated after 9? Can I rely long term on that thing or not? If I had to guess, COBOL will still be in use in 20 years from now. The demise of old technologies has been predicted so many times that it's now a joke in the industry. COBOL was already old and on its way out when I was in high school, studying those languages that would SURELY replace it, in the beginning of the 90s of the last century, almost 35 years ago. I understand that a young industry, that mostly runs on young people because of the ageism in SV, feels it can fix everything in a few months, but that's the illusion: we collectively can't. The more a technology stays in place, the more time it will stay relevant. There's also a law about it, I don't remember the name now.
devwastaken 4y ago
Apple has been migrating everything to Swift in part because of this. There is no longer a reason to be using C/C+ in production for OS use. It's fun for prototyping to get something quick and dirty, not something to be trusted in the field where it's going to be attacked. When we design physical products we put them through rigorous testing to ensure they withstand abuse, and we change the materials and entire toolsets to create safer products. Rust has significant benefits beyond just the memory part. Because the application is so detailed the compiler can be significantly smarter. Unlike in C/C+ where certain optimizations can't be used because there's not enough information described by the code.
- hnlmorg 4y ago
  And physical products are constantly being recalled because problems are found on them after they’ve been released. The problem we have here isn’t that a 40 year old software was written in C. It is that open source doesn’t have the resources to replace a lot of its core infrastructure, like how commercial physical products do. All of the discussions in this thread about lack of legislation and even taking developers to court completely miss the root problem that there simply isn’t the man power to make these changes. So what’s the solution? 1. Get businesses to invest more into open source? They’ll just pivot to closed source projects and we’ll be in the same dilemma we are now but with far more bad code out there and far less ability to patch it. 2. We could get the governments to pay for open source development? That’s never going to be popular. Particularly in circles like HN which are generally against government intervention. 3. Or we could just keep patching older software in C when these bugs crop up. …and this is exactly why we are in the situation we are in. Because it is the only practical solution. It might not be pretty and it might lead to repeated complaints about old code but until open source funding changes drastically, it’s the only option available to us. Source: someone who writes open source software in memory safe languages but has to do so as a hobby because I also have a family to feed.

quotemstr 4y ago

Too many people think they can write memory safe code when they can't, and they can't because they're human beings, and humans cannot write correct C. Then, when you point out that programs written in some languages are immune to entire classes of vulnerability, these people write things like this: > Memory safeness is just an illusion We're not going to make any progress as an industry until we stop indulging people who think C is cool.

blacklight 4y ago
I'm not saying that it's impossible to break things in Rust/Go/Dart. Im saying that it's several orders of magnitude more difficult. Bugs like these show that, no matter your level of experience in C/C++, you ALWAYS have a high chance of messing things up on memory access, because there are so many things you have to keep in mind while writing your code - and often these bugs are also very difficult to spot. We need to favour languages that don't make things perfect (there's no such thing), but that at least make it much harder for things to break. Like Stroustrup said, we need guns that make it harder to shoot your own leg.
- pjmlp 4y ago
  Hence why the industry needs a little legal help push, just like when dealing with hazardous chemicals and sharp cutting tools. Thankfully it is starting to take place.
asveikau 4y ago
It is an illusion, in the sense that memory doesn't actually work "safely", and safety needs to be built from lower level primitives. Mind you, being an illusion is not criticism, and doesn't make it less of a good idea. There's people that believe all perception is illusion. Do they stop perceiving?
- pjmlp 4y ago
  Not it isn't, dealing with chemicals and sharp tools is hazardous, hence why there are laws in place about work practices that must be obeyed. High integrity computing already has them, we just need a little push to apply them everywhere with liability for non compliance.
  - asveikau 4y ago
    The laws are not a property of the universe. They're a convention. Illusory. I'm not advocating not having laws, or saying they don't have value.
    - pjmlp 4y ago
      They look pretty physical for those affected by them.

asveikau 4y ago

> we would have figured out better ways to deal with memory other than those buggy malloc, free It's not malloc and free that are buggy here. Fundamentally, there is some layer of the system that needs to work like that. What people tend to advocate when they say they don't like this is keeping the size of code that needs to reason that way small and restricted. I.e. not writing an entire X server that way. But the allocator will still be there. Something needs to chop up the buffers in an unsafe way somewhere.

blacklight 4y ago
Of course, we all agree that on a low level the memory black magic still needs to happen. But the developer shouldn't be in charge of it - just like today's developers don't decide on which CPU register a certain variable should be stored, or how to overwrite the instruction pointer when performing a function call. I mean, of course there will always be cases where a developer needs to go this low - think of OS/firmware developers. But that doesn't apply to 99.9% of the developers out there. Most of the developers out there want a programming language where they can easily declare an array, append or remove stuff from it without breaking anything, and when there's no piece of code left that references that piece of memory then it should be deallocated - in such a way that should be invisible to the developer. So C/C++ nowadays cater to the 0.1% that needs to tinker with every bit of the memory, and those who love those languages want us to believe that their use-case is the same as the remaining 99.9%.
- peoplefromibiza 4y ago
  > I mean, of course there will always be cases where a developer needs to go this low it made total sense when writing X11 though which made X11 last so long and still totally work we'll see in how many years Wayland will be rewritten because it's legacy, it still doesn't work everywhere after 15 years of trying hard.

semi-extrinsic 4y ago

If you think of code as infrastructure, it's not insane, it's the expected outcome. Bridges were built differently in the 1960s than they are today. We are not tearing down all the old bridges and building new ones, that would be crazy. Instead we need to spend enough time and money on maintenance of the old bridges, and replace them when that becomes the better option. When we fail to conduct proper maintenance, accidents happen, like Ponte Morandi.

devwastaken 4y ago
Old bridges are being replaced all the time. Modern bridges aren't built like the 1960's anymore, yet with code it's like we're still in 1990 when a new project starts.
pjmlp 4y ago
We are taking people to court that build broken bridges.
- nix23 4y ago
  We aslo bring people to court who endanger/kill peoples per software-(bugs)... I also have seen many bridges where no responsibility can be assumed (especially in the mountains).
  - pjmlp 4y ago
    > We aslo bring people to court who endanger/kill peoples per software-(bugs)... Only in high integrity computing scenarios. All kinds of refunds and lawsuits from physical goods should apply to software as well. Regarding the bridges, just because "guilt died alone" as we say back home, doesn't mean we should disregard the bigger picture.
timeon 4y ago
Unlike software, civil engineering is subjected to regulations.

peoplefromibiza 4y ago

> We're in 2023, and I'm still reading about pieces of software that can be exploited because of poor memory management (either unexpected reads, unexpected writes, or incorrect deallocation). wait until 2123 when you will still read about them and Wayland will almost be ready. side note: can we please stop this nonsense whining around infrastructures? yes, infrastructures are old, they are old because they work, they work because they were carefully engineered and maintained. A bug in some infrastructure code is not the end of the World, it's, on the contrary, a sign of its vitality. Yes, roads still have holes in them, even though we invented them thousands years ago, it doesn't make them less useful. EDIT: rewriting X11 proved to be almost a failure, after 15 years, in 2023, on my laptop KDE/Wayland can't start the plasmashell, while X11 still rocks the boat without a glitch. This constant lamentation about "safe languages", that sounds like the sirens in The Odyssey, and the promotion of "rewrite it!" - in this case X11 (AGAIN!) - in some new shiny language of today like if 40 years totally make the difference between the past and the future, it's the most serious form of delusion I have ever witnessed in my whole life.

blacklight 4y ago
The problem is that, as IT technologies become older, there will be less and less people who can understand what's going on, debug and fix things. At that point, degradation becomes inevitable, and projects go in maintenance-only mode because adding new features is just too hard and risky. Have you wondered why the X.Org server still fails at doing simple things like inferring the DPI and supporting retina displays without extra configuration? Or why you need external window compositors? Have you ever tried to play with the X11 C API, just to land on cryptic documentation that hasn't been updated in 25 years? Or, worse, dive into the source code of the server, and find 40 years of workarounds that make you feel like taking one straw away will make the whole castle collapse? Note that the same also applies to other pieces of software (like xterm) that are way past their expiry date. Software should not get into this stage and still be massively used in production. We should avoid projects like X.Org from becoming the next COBOL.
- peoplefromibiza 4y ago
  > At that point, degradation becomes inevitable, and projects go in maintenance-only mode because adding new features is just too hard and risky. I repeat it: Wayland is 15 years old and it's written in C. I'm waiting for a rewrite in Rust or whatever, so in 15 years I will still be using X11, because it's the only thing that works reliably across my devices, old and new. > Have you ever tried to play with the X11 C API yes, since 1996. > and find 40 years of workarounds that's called "SOLUTIONS" in professionals' World. The real World is full of edge cases, if your code is dealing with none of them, your solution is probably fragile. https://www.luckymethod.com/2013/03/the-big-redesign-in-the-sky/ https://www.luckymethod.com/2013/03/the-big-redesign-in-the-... > Software should not get into this stage and still be massively used in production > We should avoid projects like X.Org from becoming the next COBOL. That's the wrong way to look at it. We should ask ourselves: why COBOL is still in use after so long, while a JavaScript framework lasts 6 months and it's deprecated after 9? Can I rely long term on that thing or not? If I had to guess, COBOL will still be in use in 20 years from now. The demise of old technologies has been predicted so many times that it's now a joke in the industry. COBOL was already old and on its way out when I was in high school, studying those languages that would SURELY replace it, in the beginning of the 90s of the last century, almost 35 years ago. I understand that a young industry, that mostly runs on young people because of the ageism in SV, feels it can fix everything in a few months, but that's the illusion: we collectively can't. The more a technology stays in place, the more time it will stay relevant. There's also a law about it, I don't remember the name now.

devwastaken 4y ago

Apple has been migrating everything to Swift in part because of this. There is no longer a reason to be using C/C+ in production for OS use. It's fun for prototyping to get something quick and dirty, not something to be trusted in the field where it's going to be attacked. When we design physical products we put them through rigorous testing to ensure they withstand abuse, and we change the materials and entire toolsets to create safer products. Rust has significant benefits beyond just the memory part. Because the application is so detailed the compiler can be significantly smarter. Unlike in C/C+ where certain optimizations can't be used because there's not enough information described by the code.

hnlmorg 4y ago
And physical products are constantly being recalled because problems are found on them after they’ve been released. The problem we have here isn’t that a 40 year old software was written in C. It is that open source doesn’t have the resources to replace a lot of its core infrastructure, like how commercial physical products do. All of the discussions in this thread about lack of legislation and even taking developers to court completely miss the root problem that there simply isn’t the man power to make these changes. So what’s the solution? 1. Get businesses to invest more into open source? They’ll just pivot to closed source projects and we’ll be in the same dilemma we are now but with far more bad code out there and far less ability to patch it. 2. We could get the governments to pay for open source development? That’s never going to be popular. Particularly in circles like HN which are generally against government intervention. 3. Or we could just keep patching older software in C when these bugs crop up. …and this is exactly why we are in the situation we are in. Because it is the only practical solution. It might not be pretty and it might lead to repeated complaints about old code but until open source funding changes drastically, it’s the only option available to us. Source: someone who writes open source software in memory safe languages but has to do so as a hobby because I also have a family to feed.