Jump to page: 1 2
Thread overview
Are programs/OSes written in D more secure than programs written in C/C++?
Jun 06, 2012
J.Varghese
Jun 06, 2012
Justin Whear
Jun 07, 2012
Paulo Pinto
Jun 07, 2012
Kapps
Jun 07, 2012
Mehrdad
Jun 07, 2012
Mehrdad
Jun 07, 2012
Regan Heath
Jun 07, 2012
Kapps
Jun 07, 2012
Mehrdad
Jun 07, 2012
Paulo Pinto
Jun 07, 2012
J.Varghese
Jun 07, 2012
Kagamin
Jun 08, 2012
Nick Sabalausky
Jun 08, 2012
J.Varghese
Jun 08, 2012
Walter Bright
June 06, 2012
I'm sure most of you have heard of the recent increase of high
profile hacking and security violations. The PlayStation Network,
RSA, LinkedIn, (today) and thousands of lower profile attacks.
The Flame trojan also marks the rise of highly sophisticated
state-sponsored cyberweapons.

I'm not a programmer, so can someone explain this to me: Will
programs and operating systems written in D be safer (I speak of
both memory safety and security bugs) than existing operating
systems written in C and C++? If so, what features and attributes
of D make this the case? How much safer is it? Would it be
possible to identify all the bugs in an OS written in D (within a
reasonable timeframe) or is that still a pipedream?

Thanks for replying. I have followed the development of D for a while. I just want to know how much safer D is than other languages. Curiosity and all that.
June 06, 2012
On 07-06-2012 00:04, J.Varghese wrote:
> I'm sure most of you have heard of the recent increase of high
> profile hacking and security violations. The PlayStation Network,
> RSA, LinkedIn, (today) and thousands of lower profile attacks.
> The Flame trojan also marks the rise of highly sophisticated
> state-sponsored cyberweapons.
>
> I'm not a programmer, so can someone explain this to me: Will
> programs and operating systems written in D be safer (I speak of
> both memory safety and security bugs) than existing operating
> systems written in C and C++? If so, what features and attributes
> of D make this the case? How much safer is it? Would it be
> possible to identify all the bugs in an OS written in D (within a
> reasonable timeframe) or is that still a pipedream?
>
> Thanks for replying. I have followed the development of D for a while. I
> just want to know how much safer D is than other languages. Curiosity
> and all that.

No programming language (today) can make cryptosystems more or less mathematically secure. Nor can a programming language make your business' IT infrastructure less susceptible to attacks (badly configured firewalls, SQL injections, you name it).

What D *can* do, if you use the features that it gives you, is prevent a set of common exploits in programs. For instance, D's slicing mechanism for arrays is significantly more secure than raw operations on pointers because an out-of-bounds read/write will cause the program to terminate. So, buffer over-runs are not exploitable. Further, D has type-safe variadic functions, so common printf exploits are impossible too. D also prevents stack smashing (if you compile with GDC), but C has this feature too.

So what D does is that it prevents small but common exploits in programs. But that doesn't mean that your program is cryptographically sound/secure, for example.

As always, It Depends (TM). :)

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
June 06, 2012
On Thu, 07 Jun 2012 01:01:55 +0200, Alex Rønne Petersen wrote:

> On 07-06-2012 00:04, J.Varghese wrote:
>> I'm not a programmer, so can someone explain this to me: Will programs and operating systems written in D be safer (I speak of both memory safety and security bugs) than existing operating systems written in C and C++? If so, what features and attributes of D make this the case? How much safer is it? Would it be possible to identify all the bugs in an OS written in D (within a reasonable timeframe) or is that still a pipedream?
>>
>> Thanks for replying. I have followed the development of D for a while. I just want to know how much safer D is than other languages. Curiosity and all that.
> 
> No programming language (today) can make cryptosystems more or less
> mathematically secure. ...
> 
> So what D does is that it prevents small but common exploits in programs. But that doesn't mean that your program is cryptographically sound/secure, for example.
> 
> As always, It Depends (TM). :)

I'd add to this list a philosophy decision: D tries to make the correct way the easiest way and path of least resistance. A highly disciplined and skilled C coder could accomplish the effect, but practically speaking, this can help eliminate a class of errors due to programmer laziness or lack of understanding.

Justin
June 07, 2012
On Wednesday, 6 June 2012 at 22:04:27 UTC, J.Varghese wrote:
> I'm not a programmer, so can someone explain this to me: Will
> programs and operating systems written in D be safer (I speak of
> both memory safety and security bugs) than existing operating
> systems written in C and C++? If so, what features and attributes
> of D make this the case? How much safer is it? Would it be
> possible to identify all the bugs in an OS written in D (within a
> reasonable timeframe) or is that still a pipedream?
>

D helps with a few security bugs related to memory by making a few things nicer.

But probably not the ones you're thinking of. The VAST majority of security problems you hear of are simply due to stupidity. SQL injection is probably one of the most common exploits now-a-days, and no programming language will save you from that. These exploits aren't directed to the language, but rather to external software / protocols and libraries to interface with them. For example, with SQL, you send a message to an external program (a database). SQL injection then is an attacker being able to put in their own things into that message when the server sends the messagew with your input.

However, in your libraries, there are ways to prevent certain bugs that are present in D but not so much in most other languages. For example, with most other languages, if you want someone to input a string to your function (in this case a string that represents a message to send to a SQL database), you don't know how that string was formed. In D, you could guarantee that this string was determined at compile time and thus prevent any strings that are made with user input, and thus completely prevent SQL injection. SQL databases have a protocol where you can send the input fields seperately, and just have the original message refer to them instead of give the actual values, and that's what you would use here. Again though, this is just D providing a feature for a library to use, not something that the D compiler will do for you.
June 07, 2012
> no programming language will save you from that

LINQ isn't exactly susceptible to SQL injection. :P
June 07, 2012
On 07-06-2012 07:04, Mehrdad wrote:
>> no programming language will save you from that
>
> LINQ isn't exactly susceptible to SQL injection. :P

LINQ can't mutate the state of the DB, only query it. LINQ far from covers everything.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
June 07, 2012
On Thursday, 7 June 2012 at 05:09:27 UTC, Alex Rønne Petersen wrote:
> On 07-06-2012 07:04, Mehrdad wrote:
>>> no programming language will save you from that
>>
>> LINQ isn't exactly susceptible to SQL injection. :P
>
> LINQ can't mutate the state of the DB, only query it. LINQ far from covers everything.

True enough, although it's not too difficult to imagine an extension of LINQ where that is indeed possible.

Nonetheless, the following /is/ called "LINQ to SQL" (why, I don't know):
http://msdn.microsoft.com/en-us/library/bb386941.aspx
June 07, 2012
On Thursday, 7 June 2012 at 05:04:30 UTC, Mehrdad wrote:
>> no programming language will save you from that
>
> LINQ isn't exactly susceptible to SQL injection. :P

I would consider Linq to SQL more of a library than a language, even though it has compiler support. It's also something that should be doable in D (and in a more optimized way than in C#), especially if that __traits(codeof) pull gets added.
June 07, 2012
On Thursday, 7 June 2012 at 06:33:41 UTC, Kapps wrote:
> On Thursday, 7 June 2012 at 05:04:30 UTC, Mehrdad wrote:
>>> no programming language will save you from that
>>
>> LINQ isn't exactly susceptible to SQL injection. :P
>
> I would consider Linq to SQL more of a library than a language, even though it has compiler support. It's also something that should be doable in D (and in a more optimized way than in C#), especially if that __traits(codeof) pull gets added.

Huh.. for me, it's exactly the opposite.

You can use LINQ with _any_ library that provides the functionality.

The library itself doesn't really do much -- it's the syntax (& transformation) that's the key!
June 07, 2012
On Wednesday, 6 June 2012 at 22:04:27 UTC, J.Varghese wrote:
> I'm sure most of you have heard of the recent increase of high
> profile hacking and security violations. The PlayStation Network,
> RSA, LinkedIn, (today) and thousands of lower profile attacks.
> The Flame trojan also marks the rise of highly sophisticated
> state-sponsored cyberweapons.
>
> I'm not a programmer, so can someone explain this to me: Will
> programs and operating systems written in D be safer (I speak of
> both memory safety and security bugs) than existing operating
> systems written in C and C++? If so, what features and attributes
> of D make this the case? How much safer is it? Would it be
> possible to identify all the bugs in an OS written in D (within a
> reasonable timeframe) or is that still a pipedream?
>
> Thanks for replying. I have followed the development of D for a while. I just want to know how much safer D is than other languages. Curiosity and all that.

D has a few language features that help to minimize exploits:

- slices
- bounds checking
- more restrict type checking
- GC
- reference parameters
- proper strings
- security layers among modules (system, trusted, safe)

Most C and C++ security exploits are due to:

- pointer arithmetic
- null terminated strings
- lack of bounds checking on array access
- usage of pointers to change input arguments

Sure enough, static analysis tools can help, but not everyone makes
use of them. Note that C++ library can help, but requires that the developers
play by the rules.

But no language is 100% full proof. You still need to take care data
is properly handled (SQL, passwords, etc) and if the OS does not provide
the proper security mechanisms, you can still tweak the assembly code.

--
Paulo

« First   ‹ Prev
1 2