3 ms·

How is C not memory safe? If I access memory I didn't allocate the OS shuts the program down. Is that not memory safety? (Unless you're running it on bare meta

by dheera 2y ago

How is C not memory safe? If I access memory I didn't allocate the OS shuts the program down. Is that not memory safety? (Unless you're running it on bare metal ...)

rictic 2y ago
Memory errors can be exploited by a clever adversary to control your process in a variety of unpleasant ways, see: https://en.wikipedia.org/wiki/Memory_safety#Types_of_memory_errors https://en.wikipedia.org/wiki/Memory_safety#Types_of_memory_...
deleted 2y ago
[deleted]
hot_gril 2y ago
That's not what memory safety refers to.
kortilla 2y ago
This is not a question for HN at this point. It’s like asking why SQL query forming via string concatenation of user inputs is unsafe. Google it, C memory boundary issues have been a problem for security forever.
- TeMPOraL 2y ago
  > It’s like asking why SQL query forming via string concatenation of user inputs is unsafe. To be honest, that's a surprisingly deep question, and the answer is something I'm yet to see any developer I worked with understand. For example, did you know that SQL injection and XSS are really the same problem? And so is using template systems[0] like Mustache? In my experience, very few people appreciate that the issue with "SQL query forming via string concatenation" isn't in the "SQL" part, but in the "string concatenation" part. -- [0] - https://en.wikipedia.org/wiki/Template_processor https://en.wikipedia.org/wiki/Template_processor
  - codetrotter 2y ago
    The problem that causes it is in photo cases that a flat string representation kind of mixes code and data. And therefore escaping (such as not allowing quotes in the user input to terminate quotes in your query, or not allowing html tags to be opened or closed by user input, nor allowing html attributes to be opened or closed by the user input, etc) is needed.
  - cowsandmilk 2y ago
    Really, the problem is in combining tainted input strings with string concatenation. If you have certain guarantees on the input strings, concatenation can be safe. That said, I still wouldn’t use it since there are few guarantees that future code wouldn’t introduce tainted strings.
  - IshKebab 2y ago
    > In my experience, very few people appreciate that the issue with "SQL query forming via string concatenation" isn't in the "SQL" part, but in the "string concatenation" part. Really? To me it's pretty obvious that not escaping properly is the issue, and therefore the same issue applies wherever you need escaping. I don't think I've ever heard anyone say that SQL itself was the problem with SQL injection. (Although you certainly could argue that - SQL could be designed in such a way that prepared statements are mandatory and there's simply no syntax for inline values.)
koolba 2y ago
> If I access memory I didn't allocate the OS shuts the program down. The real problem is when you access memory that did allocate.
- dheera 2y ago
  So we need a new flag for gcc that writes zeros to any block of allocated memory before malloc returns, not a new language.
  - KMag 2y ago
    You'd probably want an alternative libc implementation rather than a compiler flag. However, calloc everywhere won't save you from smashing the stack or pointer type confusion (a common source of JavaScript exploits). Very rarely is leftover data from freed memory the source of an exploit.
  - kelnos 2y ago
    That wouldn't make it safe. It would just make it crash in a different way, and still be vulnerable to exploitation by an attacker.
  - saagarjha 2y ago
    We have that already. There are still other problems that exist.
  - BlobberSnobber 2y ago
    If only the very competent people that decided to create Rust had thought of asking you for the solution instead... Have a little humility.
patmorgan23 2y ago
I think you have a missunderstanding on what memory safety is. Memory safety means that your program is free of memory corruption bugs (such as buff overflow or under flow bugs) that could be used to retrieve data the user isn't supposed to have, or can be used to inject code/commands that then get run in the programs process. These don't get shut down by the OS because the program is interacting with its own memory.
kelnos 2y ago
No, that's a security vulnerability waiting for someone to exploit.
dataking 2y ago
Highly recommend Alex Gaynor's intro to memory unsafety https://alexgaynor.net/2019/aug/12/introduction-to-memory-unsafety-for-vps-of-engineering/ https://alexgaynor.net/2019/aug/12/introduction-to-memory-un...

by dheera 2y ago

How is C not memory safe? If I access memory I didn't allocate the OS shuts the program down. Is that not memory safety? (Unless you're running it on bare metal ...)

rictic 2y ago

Memory errors can be exploited by a clever adversary to control your process in a variety of unpleasant ways, see: https://en.wikipedia.org/wiki/Memory_safety#Types_of_memory_errors https://en.wikipedia.org/wiki/Memory_safety#Types_of_memory_...

deleted 2y ago

[deleted]

hot_gril 2y ago

That's not what memory safety refers to.

kortilla 2y ago

This is not a question for HN at this point. It’s like asking why SQL query forming via string concatenation of user inputs is unsafe. Google it, C memory boundary issues have been a problem for security forever.

TeMPOraL 2y ago
> It’s like asking why SQL query forming via string concatenation of user inputs is unsafe. To be honest, that's a surprisingly deep question, and the answer is something I'm yet to see any developer I worked with understand. For example, did you know that SQL injection and XSS are really the same problem? And so is using template systems[0] like Mustache? In my experience, very few people appreciate that the issue with "SQL query forming via string concatenation" isn't in the "SQL" part, but in the "string concatenation" part. -- [0] - https://en.wikipedia.org/wiki/Template_processor https://en.wikipedia.org/wiki/Template_processor
- codetrotter 2y ago
  The problem that causes it is in photo cases that a flat string representation kind of mixes code and data. And therefore escaping (such as not allowing quotes in the user input to terminate quotes in your query, or not allowing html tags to be opened or closed by user input, nor allowing html attributes to be opened or closed by the user input, etc) is needed.
- cowsandmilk 2y ago
  Really, the problem is in combining tainted input strings with string concatenation. If you have certain guarantees on the input strings, concatenation can be safe. That said, I still wouldn’t use it since there are few guarantees that future code wouldn’t introduce tainted strings.
- IshKebab 2y ago
  > In my experience, very few people appreciate that the issue with "SQL query forming via string concatenation" isn't in the "SQL" part, but in the "string concatenation" part. Really? To me it's pretty obvious that not escaping properly is the issue, and therefore the same issue applies wherever you need escaping. I don't think I've ever heard anyone say that SQL itself was the problem with SQL injection. (Although you certainly could argue that - SQL could be designed in such a way that prepared statements are mandatory and there's simply no syntax for inline values.)

koolba 2y ago

> If I access memory I didn't allocate the OS shuts the program down. The real problem is when you access memory that did allocate.

dheera 2y ago
So we need a new flag for gcc that writes zeros to any block of allocated memory before malloc returns, not a new language.
- KMag 2y ago
  You'd probably want an alternative libc implementation rather than a compiler flag. However, calloc everywhere won't save you from smashing the stack or pointer type confusion (a common source of JavaScript exploits). Very rarely is leftover data from freed memory the source of an exploit.
- kelnos 2y ago
  That wouldn't make it safe. It would just make it crash in a different way, and still be vulnerable to exploitation by an attacker.
- saagarjha 2y ago
  We have that already. There are still other problems that exist.
- BlobberSnobber 2y ago
  If only the very competent people that decided to create Rust had thought of asking you for the solution instead... Have a little humility.

patmorgan23 2y ago

I think you have a missunderstanding on what memory safety is. Memory safety means that your program is free of memory corruption bugs (such as buff overflow or under flow bugs) that could be used to retrieve data the user isn't supposed to have, or can be used to inject code/commands that then get run in the programs process. These don't get shut down by the OS because the program is interacting with its own memory.

kelnos 2y ago

No, that's a security vulnerability waiting for someone to exploit.

dataking 2y ago

Highly recommend Alex Gaynor's intro to memory unsafety https://alexgaynor.net/2019/aug/12/introduction-to-memory-unsafety-for-vps-of-engineering/ https://alexgaynor.net/2019/aug/12/introduction-to-memory-un...