4 ms·

I agree. This is why rust and go don't need it. Address space randomization is an attempt by the OS to workaround language problems (specifically C). Nothing ag

by _wldu 7y ago

I agree. This is why rust and go don't need it. Address space randomization is an attempt by the OS to workaround language problems (specifically C). Nothing against C, I love it, but people really need to move away from it where possible.

HorstG 7y ago
Rust and Go both can have C-based libs linked to their address space thus exposing them to the same problems ASLR diminishes (I accidentially wrote "solves" here. ASLR solves nothing, it just makes exploits harder. It's a holey raincoat...). Also, both language runtimes and compilers might have flaws. "don't need" is dangerous hybris imho, of the same kind that was the downfall of Java security. Lots of Java exploits were actually just broken linked versions of libjpeg and others. No single measure will ever be sufficient, one should never become complacent like that...
saagarjha 7y ago
Since at least Rust depends on the system C library, it gets ASLR whether it needs it or not.
pjmlp 7y ago
Plenty of languages don't need it, even some older than C. This all comes down to C designers ignoring the security best practices of other systems programming languages, and UNIX clones having mainstream adoption. Morris worm (1988) wouldn't have been possible in regular Modula-2 (1978) code, nor Ada (1983), Mesa (1976), ESPOL/NEWP (1961), PL/I (1964), PL/S (1974), BLISS (1970), just citing a couple of them. Yet C17 still doesn't provide language features to prevent another Morris worm, and the security Annex was made optional instead.
- roddux 7y ago
  >ignoring the security best practices of other systems programming languages Can you please expand on this point?
  - pjmlp 7y ago
    Bounds checking, explicit unsafe blocks, proper strings, explicit type conversions, proper enumerations, checked arithmetic. For example, ESPOL/NEWP was the first systems programming language with explicit unsafe blocks, 8 years before C came into the world. So hardware that was much weaker than PDP-11, and yet capable of supporting such security features. Burroughs B5000 OS is still being developed, nowadays known as Unisys ClearPath MCP, and its top selling feature is being a mainframe system for customers whose security is the top priority.
    - saagarjha 7y ago
      > Burroughs B5000 OS is still being developed, nowadays known as Unisys ClearPath MCP, and its top selling feature is being a mainframe system for customers whose security is the top priority. What's special about it?
      - pjmlp 7y ago
        Implemented in a systems programming language has everything security related that C lacks. > Bounds checking, explicit unsafe blocks, proper strings, explicit type conversions, proper enumerations, checked arithmetic. Plus a capabilities based security access, and unsafe blocks taint binaries, requiring admin permission to be executed.
        saagarjha 7y ago
        Are these OS or hardware features?
        pjmlp 7y ago
        Language and OS features. Recent hardware versions use Xeons. Again, just features missing from C, and available in other languages. Another notable feature, it did not make use of any Assembly, in 1961, because all CPU features are exposed as compiler intrinsics.

by _wldu 7y ago

HorstG 7y ago

Rust and Go both can have C-based libs linked to their address space thus exposing them to the same problems ASLR diminishes (I accidentially wrote "solves" here. ASLR solves nothing, it just makes exploits harder. It's a holey raincoat...). Also, both language runtimes and compilers might have flaws. "don't need" is dangerous hybris imho, of the same kind that was the downfall of Java security. Lots of Java exploits were actually just broken linked versions of libjpeg and others. No single measure will ever be sufficient, one should never become complacent like that...

saagarjha 7y ago

Since at least Rust depends on the system C library, it gets ASLR whether it needs it or not.

pjmlp 7y ago

Plenty of languages don't need it, even some older than C. This all comes down to C designers ignoring the security best practices of other systems programming languages, and UNIX clones having mainstream adoption. Morris worm (1988) wouldn't have been possible in regular Modula-2 (1978) code, nor Ada (1983), Mesa (1976), ESPOL/NEWP (1961), PL/I (1964), PL/S (1974), BLISS (1970), just citing a couple of them. Yet C17 still doesn't provide language features to prevent another Morris worm, and the security Annex was made optional instead.

roddux 7y ago
>ignoring the security best practices of other systems programming languages Can you please expand on this point?
- pjmlp 7y ago
  Bounds checking, explicit unsafe blocks, proper strings, explicit type conversions, proper enumerations, checked arithmetic. For example, ESPOL/NEWP was the first systems programming language with explicit unsafe blocks, 8 years before C came into the world. So hardware that was much weaker than PDP-11, and yet capable of supporting such security features. Burroughs B5000 OS is still being developed, nowadays known as Unisys ClearPath MCP, and its top selling feature is being a mainframe system for customers whose security is the top priority.
  - saagarjha 7y ago
    > Burroughs B5000 OS is still being developed, nowadays known as Unisys ClearPath MCP, and its top selling feature is being a mainframe system for customers whose security is the top priority. What's special about it?
    - pjmlp 7y ago
      Implemented in a systems programming language has everything security related that C lacks. > Bounds checking, explicit unsafe blocks, proper strings, explicit type conversions, proper enumerations, checked arithmetic. Plus a capabilities based security access, and unsafe blocks taint binaries, requiring admin permission to be executed.
      - saagarjha 7y ago
        Are these OS or hardware features?
        pjmlp 7y ago
        Language and OS features. Recent hardware versions use Xeons. Again, just features missing from C, and available in other languages. Another notable feature, it did not make use of any Assembly, in 1961, because all CPU features are exposed as compiler intrinsics.