[HN Gopher] Securing tomorrow's software: the need for memory sa...
___________________________________________________________________
Securing tomorrow's software: the need for memory safety standards
Author : todsacerdoti
Score : 49 points
Date : 2025-02-26 18:36 UTC (4 hours ago)
(HTM) web link (security.googleblog.com)
(TXT) w3m dump (security.googleblog.com)
| anonzzzies wrote:
| Use Rust for kernel/system programming, use Lisp/Go/Java/C# for
| backend, use Typescript+wasm for frontend. We have everything
| already.
| bigtimesink wrote:
| This, but I'm getting tired of people using Rust for things
| that really should be in C# or Java.
| laerus wrote:
| "really should be" ?
|
| "in C# or Java" ?
|
| where do you even base these claims? Do you know what C# and
| Java threads have that Rust doesn't? data races. And don't
| get me stated on the biggest paradigm failure that is OOP.
| bigtimesink wrote:
| Projects I've seen at work. Projects posted on Hacker News.
| Data races aren't usually an issue for backend services,
| and modern Java/C# is multi-paradigm.
| pdimitar wrote:
| > _Projects I 've seen at work. Projects posted on Hacker
| News._
|
| Appeal to popularity: not impressive. Hangings at dawn
| were popular at one time as well. Now tell me you support
| them because they were popular.
|
| > _Data races aren 't usually an issue for backend
| services, and modern Java/C# is multi-paradigm._
|
| - They are not an issue because the bugs forever go
| unfixed and people just shrug and restart the container /
| VM.
|
| - Multi-paradigm never works. The team picks one paradigm
| and every newcomer is forced into it.
|
| You'll have to be a bit more convincing.
| legulere wrote:
| Both have a garbage collection though that lead to higher
| developer productivity than compared to rust's affine
| types.
| brink wrote:
| > higher developer productivity
|
| Where have you been the past 5 years? Rust developers are
| insanely productive.
|
| Can we put this myth to rest already? Rust being an
| "unproductive language" is thoroughly dis-proven.
| hello_moto wrote:
| Rust is the silver bullet we all been waiting for?
| ramon156 wrote:
| No, that's the other end of the stick. Its en par with
| other languages
| neonsunset wrote:
| There are domains where C# (and F#) productivity stems
| from similar reasons why writing a game in something that
| isn't Rust might be more productive _without_ even
| sacrificing performance (or, at least, not to the drastic
| extent).
|
| I can give you an example: var number =
| 0; var delay = Task.Delay(1000); for
| (var i = 0; i < 10; i++) {
| Task.Run(() => { while
| (!delay.IsCompleted) {
| Interlocked.Increment(ref number); }
| }); } await delay;
|
| How would you write this idiomatically in Rust without
| using unsafe?
|
| To avoid misunderstanding, I think Rust is a great
| language and even if you are a C# developer who does not
| plan to actively use it, learning Rust is of great
| benefit still because it forces you to tackle the
| concepts that implicitly underpin C#/F# in an explicit
| way.
| pdimitar wrote:
| > _How would you write this idiomatically in Rust without
| using unsafe?_
|
| Channels and selects. It's trivial.
| neonsunset wrote:
| Please post a snippet.
| pdimitar wrote:
| Nope, Elixir for backend.
|
| We need the BEAM VM's guarantees, not yesterday but like 20
| years ago, everywhere. The language itself does not matter. But
| we need that runtime's guarantees!
| cantalopes wrote:
| "Use lisp for backend" lol
| dmitrygr wrote:
| > we suggest establishing a common framework
|
| "If you want to kill an idea, start a committee to study it, or a
| framework to contain and guide it"
|
| :(
| neilv wrote:
| Summary: We know, we know, but don't make us rewrite everything
| in Rust.
| WalterBright wrote:
| The most common memory safety bug in released software is array
| overflow. This is easily corrected in C by adding a small
| extension:
|
| https://www.digitalmars.com/articles/C-biggest-mistake.html
| Gibbon1 wrote:
| They could fix typeof to make it something useful. Like the
| ability to take the type of something and pass it around.
|
| And add slice and buffer typedefs to the standard library.
| Especially since they added counted_by to the language.
|
| Add a way to define a slice the points to a c string.
| ajb wrote:
| Yeah, but looking back at the attempts to extend C a bit for
| safety, the only one that seems to have got market traction is
| MISRA and even then it's pretty limited. D, rust, zig etc all
| seem to have much more buy in. There must be some reason why a
| new language works better here -I mean, you're basing your
| business off D, not a C extension, right?
| BirAdam wrote:
| Being completely serious, people will use whatever works. If what
| works is written in C, people will use it. The average person
| seriously doesn't care what language a thing is written in. The
| average person cares that the software in question works. Despite
| being written in C, most software today works reasonably well. Is
| it perfect? No. Will the rusty equivalent be perfect on day 1?
| No.
| wmf wrote:
| Yeah, we know the market won't solve this. That's why people
| are talking about government standards.
| 0xbadcafebee wrote:
| How many security holes are caused by not sanitizing inputs, as
| opposed to memory safety? It feels like not sanitizing inputs is
| what _enables_ memory safety exploits, in addition to many other
| classes of security hole, yet nobody seems to talk about it.
|
| - Buffer overflow: somebody didn't sanitize the input (length of
| buffer).
|
| - Stack smashing: somebody didn't sanitize the input (length of
| input).
|
| - Format string vulnerability: somebody didn't sanitize the
| format string data.
|
| - Integer converstion vulnerability: somebody didn't sanitize the
| integer input.
|
| - SQL injection: somebody didn't sanitize the input before
| querying a database.
|
| - Cross-site scripting: somebody didn't sanitize input and it got
| submitted and executed on behalf of the user.
|
| - Remote file inclusion / Directory traversal: somebody didn't
| sanitize an input variable leading to a file path.
|
| ...and on, and on, and on. If people were as obsessed with input
| sanitization as they are with memory, I'll bet you a much larger
| percentage of attacks would be stopped. Too bad input
| sanitization isn't sexy.
| UncleMeat wrote:
| SQL Injection and XSS are actually great examples of vuln
| classes where the winning strategy is safe APIs rather than
| diligent sanitization. "Just sanitize all your user inputs" is
| hard to do correctly because it is difficult to create
| automatic rules that detect every single possible violation.
|
| Prepared statements and safe HTML construction APIs plus some
| linters that scream at you when you use the unsafe APIs works
| like magic.
| bflesch wrote:
| You're correct. It's about distinction between code and data.
|
| You should simply discern between HTML elements (code) and
| HTML text nodes (data). Same with prepared statements: Clear
| distinction between SQL code vs SQL data.
|
| You just need to ensure that your data is never interpreted
| as code.
| wepple wrote:
| Two reasons
|
| - modern languages prevent you from having to think about it at
| all. You shouldn't have to sanitize, it should work
|
| - there are a load of issues that have nothing to do with
| sanitization but everything to do with memory. Race conditions,
| type confusion, UAF to name a couple. If we focus on
| sanitization, we still need memory safety to fix those
|
| Also sanitization is non-trivial for complex inputs
| wepple wrote:
| Your distinction between stack smashing and buffer overflow is
| puzzling
| pizlonator wrote:
| So many mentions of CHERI - both in this post and in the linked
| CACM article. I doubt CHERI will be the future considering how
| long it's been around for and how few actually successes have
| come out of it.
|
| Also, hilariously, Fil-C is faster than CHERI today (the fastest
| CHERI silicon available today will be slower than Fil-C running
| on my laptop, probably by an order of magnitude). And Fil-C is
| safer.
|
| Which sort of brings up another issue - this could be a case
| where Google is trying to angle for regulations that support
| their favorite strategy while excluding competition they don't
| like.
| thephyber wrote:
| Sorry, I'm not a C specialist. What are Fil-C and CHERI? eg.
| Safe subsets of C, static analysis tools, C toolsets to ensure
| memory safety?
| warkdarrior wrote:
| CHERI is a hardware architecture and instruction set to add
| safety-related capabilities to processors. See
| https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ In
| this context a capability means a way to track and enforce
| which memory area a pointer can point into. Typically this
| has to be coupled with a compiler which will initialize the
| capability for each pointer.
|
| Fil-C seems to be a C variant that adds capabilities and
| garbage collection. See https://github.com/pizlonator/llvm-
| project-deluge/blob/delug...
| ajb wrote:
| Not really buying your thesis here: Attempts to retrofit safely
| to C have been around a lot longer than Cheri; fil-c is just
| the latest and there's no obvious reason why it should be more
| successful.
|
| The speed comparison with a laptop is just disingenuous. Is a
| device with Cheri integrated slower than one of the same class
| without?
| 0xbadcafebee wrote:
| This post seems a lot more informative to me: _" It Is Time to
| Standardize Principles and Practices for Software Memory Safety"_
| (https://cacm.acm.org/opinion/it-is-time-to-standardize-princ...)
|
| I am 100% in favor of industry standards to enforce safety. It
| should go way past just memory safety, though. Engineering
| standards should include practices and minimum requirements to
| prevent safety issues as a whole.
| binkHN wrote:
| Happy to see the mention of Kotlin's memory safety features here;
| goes a bit beyond Java with its null safety, encouragement of
| immutability and smart casting.
| iFire wrote:
| Why not mandate ecc ram?
| wmf wrote:
| Lobbying from Intel probably.
| hinkley wrote:
| I worked on a provenance system which would be so completely the
| wrong solution to this problem that I only bring it up because
| the 100,000 foot view is still relevant.
|
| I think we are eventually going to end up with some sort of
| tagged memory with what this is for (such as credentials) and
| rules about who is allowed to touch it and where it's allowed to
| go. Instead of writing yet another tool that won't let fields
| called "password" or "token" or "key" be printed into the logs,
| but misses "pk", it's going to be no printing any memory block in
| this arena, period.
|
| I also think we aren't doing enough basic things with backend
| systems like keeping just a user ID in the main database schema
| and putting all of the PII in a completely different cluster of
| machines, that has 1/10 to 1/100th of the sudoer entries on it of
| any other service in the company. I know these systems are out
| there, my complaint is we should be talking about them all the
| time, to push the Recency Effect and/or Primacy Effect hard.
___________________________________________________________________
(page generated 2025-02-26 23:00 UTC)