3 ms·

C can be secure if you follow best practices (yes, big if). Are BSD, Linux and Postgres secure?

by smitherfield 10y ago

kl4m 10y ago
Maybe
zenlikethat 10y ago
Which BSD? Postgres "maybe", Linux hell no. Constant kernel exploits
geofft 10y ago
Postgres isn't written in standard C. It's written in a derivative of C where signed integer overflow is defined as two's-complement and the strict aliasing rule is removed. Most standard C compilers also support this variant language with the compile options -fwrapv -fno-strict-aliasing. https://www.postgresql.org/message-id/1689.1134422394@sss.pgh.pa.us https://www.postgresql.org/message-id/1689.1134422394@sss.pg... If you're going to use Postgres as an example of writing secure code in a language, that's fine, but make sure you're advocating for this C variant and not for standard C. Standard C, where signed integer overflow is undefined and the strict aliasing rule exists, is extremely hard to write secure code in. http://blog.regehr.org/archives/1307 http://blog.regehr.org/archives/1307 (There's also the separate issue that most of the input paths into Postgres are trusted in some way: you don't expect malformed database files, and you often don't expect hostile queries. It's primarily the auth code that needs to be rock-solid, which is a relatively small piece of the software.)
- anarazel 10y ago
  Yea, postgres certainly assumes a lot more than the standard guarantees. Besides the above, if you look at it formally, it's pretty much impossible to have a multi-process program, connected over shared memory, that's actually fully standard compliant. Especially not when using a pre C11 environment (postgres requires C89). I think we really should have "official" variants of C that are a bit more predictable. But I guess that's not happening.
  - anarazel 10y ago
    Oh, and whoever designed the strict aliasing specs: To me they seem widely impractical. The fact that there's essentially no way to explicitly alias, without memcpy'ing, is just absurd. The standard's language is also so cryptic, that well versed people (like Regehr you linked to) can't agree with each other what the exact requirements are. The union aliasing trick isn't, to my knowledge, actually precisely standards conforming.
nl 10y ago
No. https://www.openbsd.org/errata59.html https://www.openbsd.org/errata59.html (although of course OpenBSD is pretty decent generally) https://www.cvedetails.com/vulnerability-list/vendor_id-6/Freebsd.html https://www.cvedetails.com/vulnerability-list/vendor_id-6/Fr... https://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/cvssscoremin-7/cvssscoremax-7.99/Linux-Linux-Kernel.html https://www.cvedetails.com/vulnerability-list/vendor_id-33/p... https://www.cvedetails.com/vulnerability-list/vendor_id-336/product_id-575/Postgresql-Postgresql.html https://www.cvedetails.com/vulnerability-list/vendor_id-336/...

C can be secure if you follow best practices (yes, big if). Are BSD, Linux and Postgres secure?

kl4m 10y ago

Maybe

zenlikethat 10y ago

Which BSD? Postgres "maybe", Linux hell no. Constant kernel exploits

geofft 10y ago

Postgres isn't written in standard C. It's written in a derivative of C where signed integer overflow is defined as two's-complement and the strict aliasing rule is removed. Most standard C compilers also support this variant language with the compile options -fwrapv -fno-strict-aliasing. https://www.postgresql.org/message-id/1689.1134422394@sss.pgh.pa.us https://www.postgresql.org/message-id/1689.1134422394@sss.pg... If you're going to use Postgres as an example of writing secure code in a language, that's fine, but make sure you're advocating for this C variant and not for standard C. Standard C, where signed integer overflow is undefined and the strict aliasing rule exists, is extremely hard to write secure code in. http://blog.regehr.org/archives/1307 http://blog.regehr.org/archives/1307 (There's also the separate issue that most of the input paths into Postgres are trusted in some way: you don't expect malformed database files, and you often don't expect hostile queries. It's primarily the auth code that needs to be rock-solid, which is a relatively small piece of the software.)

anarazel 10y ago
Yea, postgres certainly assumes a lot more than the standard guarantees. Besides the above, if you look at it formally, it's pretty much impossible to have a multi-process program, connected over shared memory, that's actually fully standard compliant. Especially not when using a pre C11 environment (postgres requires C89). I think we really should have "official" variants of C that are a bit more predictable. But I guess that's not happening.
- anarazel 10y ago
  Oh, and whoever designed the strict aliasing specs: To me they seem widely impractical. The fact that there's essentially no way to explicitly alias, without memcpy'ing, is just absurd. The standard's language is also so cryptic, that well versed people (like Regehr you linked to) can't agree with each other what the exact requirements are. The union aliasing trick isn't, to my knowledge, actually precisely standards conforming.

nl 10y ago

No. https://www.openbsd.org/errata59.html https://www.openbsd.org/errata59.html (although of course OpenBSD is pretty decent generally) https://www.cvedetails.com/vulnerability-list/vendor_id-6/Freebsd.html https://www.cvedetails.com/vulnerability-list/vendor_id-6/Fr... https://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/cvssscoremin-7/cvssscoremax-7.99/Linux-Linux-Kernel.html https://www.cvedetails.com/vulnerability-list/vendor_id-33/p... https://www.cvedetails.com/vulnerability-list/vendor_id-336/product_id-575/Postgresql-Postgresql.html https://www.cvedetails.com/vulnerability-list/vendor_id-336/...