www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] NSA guidance on software security

reply Paulo Pinto <pjmlp progtools.org> writes:
So it is happening,


"Memory issues in software comprise a large portion of the 
exploitable vulnerabilities in
existence. NSA advises organizations to consider making a 
strategic shift from
programming languages that provide little or no inherent memory 
protection, such as
C/C++, to a memory safe language when possible. Some examples of 
memory safe


https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF

Eventually this will move from a recomendation, to possible 
specific certification requirements to still deliver software in 
such languages.

D is not yet on the list, but who knows, it might make an 
appearance on some revised version, if someone at NSA is paying 
attention.
Nov 10 2022
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 11 November 2022 at 07:03:58 UTC, Paulo Pinto wrote:

 So it is happening,


 "Memory issues in software comprise a large portion of the 
 exploitable vulnerabilities in
 existence. NSA advises organizations to consider making a 
 strategic shift from
 programming languages that provide little or no inherent memory 
 protection, such as
 C/C++, to a memory safe language when possible. Some examples 
 of memory safe


 https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF

 Eventually this will move from a recomendation, to possible 
 specific certification requirements to still deliver software 
 in such languages.

 D is not yet on the list, but who knows, it might make an 
 appearance on some revised version, if someone at NSA is paying 
 attention.


The conspiracy continues
Nov 11 2022
prev sibling next sibling parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Friday, 11 November 2022 at 07:03:58 UTC, Paulo Pinto wrote:

 D is not yet on the list, but who knows, it might make an 
 appearance on some revised version, if someone at NSA is paying 
 attention.


I find it more surprising that Python is not on the list. But 
they just provide a few examples of safe programming languages.

But even if they decide to provide a complete list of recommended 
programming languages, in NSA's shoes I would avoid recommending 
D yet. Because is not  safe by default and the  system code in 
"-release" builds has no bounds checking (so goodbye memory 
safety). Additionally, catching arithmetic overflows is the next 
safety frontier NSA may be looking into and D has nothing good to 
offer (the checkedint library is a fig leaf and non-practical in 
reality).
Nov 11 2022
next sibling parent reply Sergey <kornburn yandex.ru> writes:
On Friday, 11 November 2022 at 08:34:39 UTC, Siarhei Siamashka 
wrote:

 On Friday, 11 November 2022 at 07:03:58 UTC, Paulo Pinto wrote:

 D is not yet on the list, but who knows, it might make an 
 appearance on some revised version, if someone at NSA is 
 paying attention.


 I find it more surprising that Python is not on the list. But 
 they just provide a few examples of safe programming languages.


The document has references about MSLs. The quote from one of 
them:
*The workshop consensus was that the Rust programming language, 
despite its initial learning curve, is particularly well-suited 
for safe systems-level development, even where performance 
requirements are important. Where performance requirements are 
less stringent, languages with garbage collection (GC), such as 
Java, Python, or Go, may be easier/simpler to use. Toolchains can 
encourage wider adoption of MSLs for programs, and thus, funding 
should be driven to the development of tools for MSLs. High 
performance MSLs like Rust should be well funded and enhanced 
with more tooling (e.g., static analysis tools, C2RUST 
converters, compiler plug-ins that facilitate translation to 
Rust/WASM), to make its ecosystem more robust.*


 But even if they decide to provide a complete list of 
 recommended programming languages, in NSA's shoes I would avoid 
 recommending D yet. Because is not  safe by default and the 
  system code in "-release" builds has no bounds checking (so 
 goodbye memory safety). Additionally, catching arithmetic 
 overflows is the next safety frontier NSA may be looking into 
 and D has nothing good to offer (the checkedint library is a 
 fig leaf and non-practical in reality).


I think it could satisfy the broad definition of MSL:
*Even with a memory safe language, memory management is not 
entirely memory safe. Most memory safe languages recognize that 
software sometimes needs to perform an unsafe memory management 
function to accomplish certain tasks. As a result, classes or 
functions are available that are recognized as non-memory safe 
and allow the programmer to perform a potentially unsafe memory 
management task. Some languages require anything memory unsafe to 
be explicitly annotated as such to make the programmer and any 
reviewers of the program aware that it is unsafe. Memory safe 
languages can also use libraries written in non-memory safe 
languages and thus can contain unsafe memory functionality. 
Although these ways of including memory unsafe mechanisms subvert 
the inherent memory safety, they help to localize where memory 
problems could exist, allowing for extra scrutiny on those 
sections of code.*
Nov 11 2022
parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Friday, 11 November 2022 at 08:52:46 UTC, Sergey wrote:

 I think it could satisfy the broad definition of MSL:


Yes, NSA could list D language provisionally. But there are still 
many unresolved memory safety issues in D ecosystem in practice. 
Many dub packages and even Phobos are not compatible with  safe 
yet. A very simple example:

```D
 safe:
import std.stdio;
void main() { readln; }
```

```
$ dmd test.d
test.d(3): Error: ` safe` function `D main` cannot call ` system` 
function `std.stdio.readln!string.readln`
/usr/lib/dmd/2.099/import/std/stdio.d(4566): 
`std.stdio.readln!string.readln` is declared here
```

Without actual  safe annotations already in place, a lot of the 
existing D code is not really safe. It's surely safer than C/C++, 
but this not good enough to convince those who are in charge of 
making programming language choice decisions in companies.

Just imagine that somebody is responsible for buying, let's say, 
parachutes to replace their existing notoriously unreliable 
brand. Given a choice between cheaper/convenient (similar to D) 
and more reliable (similar to Rust) parachute types, what will 
this person decide to buy for his team? Keep in mind that any 
future fatal accidents will be surely blamed on this person in 
the case if he decides in favor of a cheaper option...

TL;DR; You can't really sell a half baked safety nowadays.
Nov 11 2022
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 11 November 2022 at 09:32:23 UTC, Siarhei Siamashka 
wrote:

 On Friday, 11 November 2022 at 08:52:46 UTC, Sergey wrote:

 I think it could satisfy the broad definition of MSL:


 Yes, NSA could list D language provisionally. But there are 
 still many unresolved memory safety issues in D ecosystem in 
 practice. Many dub packages and even Phobos are not compatible 
 with  safe yet. A very simple example:

 ```D
  safe:
 import std.stdio;
 void main() { readln; }
 ```

 ```
 $ dmd test.d
 test.d(3): Error: ` safe` function `D main` cannot call 
 ` system` function `std.stdio.readln!string.readln`
 /usr/lib/dmd/2.099/import/std/stdio.d(4566): 
 `std.stdio.readln!string.readln` is declared here
 ```

 Without actual  safe annotations already in place, a lot of the 
 existing D code is not really safe. It's surely safer than 
 C/C++, but this not good enough to convince those who are in 
 charge of making programming language choice decisions in 
 companies.

 Just imagine that somebody is responsible for buying, let's 
 say, parachutes to replace their existing notoriously 
 unreliable brand. Given a choice between cheaper/convenient 
 (similar to D) and more reliable (similar to Rust) parachute 
 types, what will this person decide to buy for his team? Keep 
 in mind that any future fatal accidents will be surely blamed 
 on this person in the case if he decides in favor of a cheaper 
 option...

 TL;DR; You can't really sell a half baked safety nowadays.


I have been involved in high safety applications where human life 
is at risk.
We use C and C++.

The language is not what determines it, it is the tools, 
processes and organization.

I have done this for over 10 years, developing safety critical 
software and also as a control systems engineer. Both industrial 
and mobile applications.

The language is not what is important. It is everything 
surrounding it.

Have you been involved in any high SIL or PL development? I have, 
also for railway.

I know what it takes to make something. Also proven in use is 
important.
Nov 11 2022
parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Friday, 11 November 2022 at 15:07:02 UTC, Imperatorn wrote:

 TL;DR; You can't really sell a half baked safety nowadays.


 I have been involved in high safety applications where human 
 life is at risk.
 We use C and C++.

 The language is not what determines it, it is the tools, 
 processes and organization.


If you are trying to say that the programming language choice is 
irrelevant and replacing C/C++ with Rust or D won't improve 
anything, then I respectfully disagree.

Of course it's possible to implement buggy code in D or Rust. And 
correct code in C++. The other factors are surely important too 
and the programming language alone is not a panacea. Still the 
programming language choice affects the costs and risks.

Other than this, your comment didn't seem to contradict anything 
that I said. If you think that it did, then please be more 
specific.
Nov 12 2022
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 12 November 2022 at 11:31:54 UTC, Siarhei Siamashka 
wrote:

 On Friday, 11 November 2022 at 15:07:02 UTC, Imperatorn wrote:

 [...]


 If you are trying to say that the programming language choice 
 is irrelevant and replacing C/C++ with Rust or D won't improve 
 anything, then I respectfully disagree.

 Of course it's possible to implement buggy code in D or Rust. 
 And correct code in C++. The other factors are surely important 
 too and the programming language alone is not a panacea. Still 
 the programming language choice affects the costs and risks.

 Other than this, your comment didn't seem to contradict 
 anything that I said. If you think that it did, then please be 
 more specific.


You need a verified compiler
Nov 12 2022
parent Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Saturday, 12 November 2022 at 13:12:39 UTC, Imperatorn wrote:

 You need a verified compiler


Who exactly? Me? All readers of this forum? Or are you talking 
about yourself? Also your statement neither agrees nor disagrees 
with me.
Nov 12 2022
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/11/2022 1:32 AM, Siarhei Siamashka wrote:

 ```D
  safe:
 import std.stdio;
 void main() { readln; }
 ```
 
 ```
 $ dmd test.d
 test.d(3): Error: ` safe` function `D main` cannot call ` system` function 
 `std.stdio.readln!string.readln`
 /usr/lib/dmd/2.099/import/std/stdio.d(4566): `std.stdio.readln!string.readln`
is 
 declared here
 ```


Please report  safe issues to bugzilla:

https://issues.dlang.org/show_bug.cgi?id=23477
Nov 11 2022
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
On Friday, 11 November 2022 at 08:34:39 UTC, Siarhei Siamashka 
wrote:

 But even if they decide to provide a complete list of 
 recommended programming languages, in NSA's shoes I would avoid 
 recommending D yet. Because is not  safe by default and the


Just declare main  safe.


  system code in "-release" builds has no bounds checking (so 
 goodbye memory safety).


Either:
1. Don't use -release if safety is a higher priority than 
performance.
2. Use -boundscheck=on
https://dlang.org/dmd-windows.html#switch-boundscheck


 Additionally, catching arithmetic overflows is the next safety 
 frontier NSA may be looking into and D has nothing good to 
 offer (the checkedint library is a fig leaf and non-practical 
 in reality).


Memory unsafety is non deterministic. Overflow/underflow is, so 
it's much less important.
Nov 11 2022
parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Friday, 11 November 2022 at 14:52:51 UTC, Nick Treleaven wrote:

 Just declare main  safe.


Have you missed my comment, which was talking about exactly that?


 Memory unsafety is non deterministic. Overflow/underflow is, so 
 it's much less important.


Neither is deterministic. Unless you have strictly deterministic 
input data.
Nov 11 2022
next sibling parent reply bachmeier <no spam.net> writes:
On Friday, 11 November 2022 at 16:07:15 UTC, Siarhei Siamashka 
wrote:

 On Friday, 11 November 2022 at 14:52:51 UTC, Nick Treleaven 
 wrote:

 Just declare main  safe.


 Have you missed my comment, which was talking about exactly 
 that?


Your comment seems to miss the point. By declaring main  safe, 
you are ruling out various pieces of the language that are 
unsafe, which is exactly what you want if safety is the priority. 
You are arguing instead that  safe doesn't work because it 
prevents you from doing something that is potentially unsafe.
Nov 11 2022
parent Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Friday, 11 November 2022 at 16:10:56 UTC, bachmeier wrote:

 Your comment seems to miss the point. By declaring main  safe, 
 you are ruling out various pieces of the language that are 
 unsafe, which is exactly what you want if safety is the 
 priority. You are arguing instead that  safe doesn't work 
 because it prevents you from doing something that is 
 potentially unsafe.


My comment is precisely on point and you just seem to be unable 
to see a bigger picture.

NSA is just providing a general safety recommendation. Similar to 
how some sort of a health organization would generally recommend 
to eat more vegetables. Or wear a mask in public places, become 
vaccinated against COVID. Such health organization may list a few 
COVID-safe countries as an example. Suddenly the residents of 
country D are upset that their country is not listed as an 
example of a COVID-safe country. Now looking at the facts, nobody 
wears a mask in country D (they are arguing that masks are less 
important than vaccination so it's okay). Also vaccination is 
available as a free option for any D resident, but it is not 
being promoted or enforced. Why won't that damn health 
organization add country D to the list of examples of COVID-safe 
places in their newsletter? Must be a conspiracy.

Continuing that health organization allegory. One D resident 
argues that if I care about my personal safety, then I should 
just become vaccinated myself and everything will be fine. No, 
this is not fine! And this person just turns a blind eye to a 
bunch of unvaccinated people roaming in public places and 
spreading infection in the ecosystem of country D. These other 
unvaccinated people make me less safe in the D community 
regardless of my own personal safety countermeasures. Oh, and 
these people don't wear masks either.

If it's too tricky to decipher, then here are some hints:
   vaccination         =>  safe attribute
   masks               => arithmetic overflows checking
   D country           => D language
   health organization => NSA
   D resident          => bachmeier


My point is that as long as the  safe attribute is not used by 
default (with a way to opt out by overriding it), very few dub 
package authors and even Phobos authors care about safety and 
 safe attribute compatibility. The quality of their code also 
affects the safety of the others in the D ecosystem.

What's up with the standard `readln` function being incompatible 
with  safe? This even is not a new discovery and nothing was done 
about it for years: 
https://forum.dlang.org/post/eaoezjlolelmnxptlqzy forum.dlang.org

Also why do people even have to write things like 
https://forum.dlang.org/thread/ilhighccvpjzbblwyqlu forum.dlang.org about
avoiding raw pointers and malloc? Just be  safe and the compiler will complain
about potentially dangerous things.
Nov 12 2022
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
On Friday, 11 November 2022 at 16:07:15 UTC, Siarhei Siamashka 
wrote:

 On Friday, 11 November 2022 at 14:52:51 UTC, Nick Treleaven 
 wrote:

 Just declare main  safe.


 Have you missed my comment, which was talking about exactly 
 that?


You didn't mention main.


 Memory unsafety is non deterministic. Overflow/underflow is, 
 so it's much less important.


 Neither is deterministic. Unless you have strictly 
 deterministic input data.


Whatever the input data, without memory safety you can't trigger 
the bug through testing alone. It might never occur on your 
system, only on your client's. That's why the NSA recognises 
memory safety bugs as categorically worse than logic bugs or 
overflow/underflow.
Nov 11 2022
parent Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Friday, 11 November 2022 at 18:24:46 UTC, Nick Treleaven wrote:

 Just declare main  safe.


 Have you missed my comment, which was talking about exactly 
 that?


 You didn't mention main.


I apologise. I didn't think that you are unfamiliar with this 
particular language construct. Check 
https://dlang.org/spec/attribute.html and search the "affects all 
declarations until the end" substring to find the relevant part 
of documentation.

Basically you can put " safe:" in the beginning of your program 
and all functions (the main function too) will be  safe by 
default.



 Memory unsafety is non deterministic. Overflow/underflow is, 
 so it's much less important.


 Neither is deterministic. Unless you have strictly 
 deterministic input data.


 Whatever the input data, without memory safety you can't 
 trigger the bug through testing alone. It might never occur
 on your system, only on your client's.


There may be certain input data patterns, which are not properly 
stressed by your local testing setup. And only manifest 
themselves on a client's system. If that's not enough to convince 
you, there are also many CVEs that mention "integer overflow".

Moreover, paged virtual memory used in modern computers already 
provides some kind of rudimentary memory safety (with page 
granularity). Your client may get a "segmentation fault" error 
with a core dump or a crash dump file, which can be used by you 
to debug the issue. Debugging an arithmetic overflow bug may be a 
lot more tricky.


 That's why the NSA recognises memory safety bugs as 
 categorically worse
 than logic bugs or overflow/underflow.


Can you prove this claim by providing a citation?
Nov 11 2022
prev sibling next sibling parent reply Ruby The Roobster <rubytheroobster yandex.com> writes:
On Friday, 11 November 2022 at 07:03:58 UTC, Paulo Pinto wrote:

 So it is happening,


 "Memory issues in software comprise a large portion of the 
 exploitable vulnerabilities in
 existence. NSA advises organizations to consider making a 
 strategic shift from
 programming languages that provide little or no inherent memory 
 protection, such as
 C/C++, to a memory safe language when possible. Some examples 
 of memory safe


 https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF

 Eventually this will move from a recomendation, to possible 
 specific certification requirements to still deliver software 
 in such languages.

 D is not yet on the list, but who knows, it might make an 
 appearance on some revised version, if someone at NSA is paying 
 attention.


If it becomes a requirement to use memory safe languages, then 
you know that the U.S. has serious problems if they cannot even 
choose what language to program in.
Nov 11 2022
parent Tejas <notrealemail gmail.com> writes:
On Saturday, 12 November 2022 at 02:49:32 UTC, Ruby The Roobster 
wrote:

 On Friday, 11 November 2022 at 07:03:58 UTC, Paulo Pinto wrote:

 So it is happening,


 "Memory issues in software comprise a large portion of the 
 exploitable vulnerabilities in
 existence. NSA advises organizations to consider making a 
 strategic shift from
 programming languages that provide little or no inherent 
 memory protection, such as
 C/C++, to a memory safe language when possible. Some examples 
 of memory safe


 https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF

 Eventually this will move from a recomendation, to possible 
 specific certification requirements to still deliver software 
 in such languages.

 D is not yet on the list, but who knows, it might make an 
 appearance on some revised version, if someone at NSA is 
 paying attention.


 If it becomes a requirement to use memory safe languages, then 
 you know that the U.S. has serious problems if they cannot even 
 choose what language to program in.


They tried in the past to enforce just one: Ada

Look how that turned out

Even if they internally decided that they'll write all their 

on other organizations, simply because the other orgs won't 
listen and it'll not exactly be cost efficient to actually force 
them to do so
Nov 11 2022
prev sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Fri, Nov 11, 2022 at 07:03:58AM +0000, Paulo Pinto via Digitalmars-d wrote:

 So it is happening,
 
 "Memory issues in software comprise a large portion of the exploitable
 vulnerabilities in existence. NSA advises organizations to consider
 making a strategic shift from programming languages that provide
 little or no inherent memory protection, such as C/C++, to a memory
 safe language when possible. Some examples of memory safe languages

 
 https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF


[...]

This was inevitable, it was just a matter of time.  Memory-unsafe
languages have no long-term future.  In the current landscape of online
threats, memory safety is no longer an option, it's an essential
requirement.  The day will come when it will no longer be viable to use
a memory-unsafe language for anything non-trivial.


T

-- 
Time flies like an arrow. Fruit flies like a banana.
Nov 12 2022