digitalmars.D - Are programs/OSes written in D more secure than programs written in
- J.Varghese (15/15) Jun 06 2012 I'm sure most of you have heard of the recent increase of high
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (21/36) Jun 06 2012 No programming language (today) can make cryptosystems more or less
- Justin Whear (7/28) Jun 06 2012 I'd add to this list a philosophy decision: D tries to make the correct
- Paulo Pinto (7/48) Jun 07 2012 The problem is that "skilled C coders" are very hard to find.
- Kapps (27/36) Jun 06 2012 D helps with a few security bugs related to memory by making a
- Mehrdad (1/2) Jun 06 2012 LINQ isn't exactly susceptible to SQL injection. :P
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (7/9) Jun 06 2012 LINQ can't mutate the state of the DB, only query it. LINQ far from
- Mehrdad (7/13) Jun 06 2012 True enough, although it's not too difficult to imagine an
- Regan Heath (15/27) Jun 07 2012 f =
- Kapps (5/7) Jun 06 2012 I would consider Linq to SQL more of a library than a language,
- Mehrdad (6/14) Jun 06 2012 Huh.. for me, it's exactly the opposite.
- Paulo Pinto (27/45) Jun 07 2012 D has a few language features that help to minimize exploits:
- J.Varghese (9/35) Jun 07 2012 So if the causes of most C and C++ security exploits have been
- Kagamin (3/7) Jun 07 2012 You should tell how many bugs in OSes are specific to C language
- Nick Sabalausky (8/11) Jun 07 2012 It's not that predictable. It all depends on the code, the programmers, ...
- J.Varghese (1/12) Jun 08 2012 Thanks. I understand better now.
- Walter Bright (7/11) Jun 07 2012 D offers a number of features designed to reduce and even eliminate
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.
Jun 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
Jun 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'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. JustinI'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). :)
Jun 06 2012
On Wednesday, 6 June 2012 at 23:10:54 UTC, Justin Whear wrote:On Thu, 07 Jun 2012 01:01:55 +0200, Alex Rønne Petersen wrote:The problem is that "skilled C coders" are very hard to find. The company I work for does consultancy in JVM and .NET environments, and I cry every time I do code review in languages that are supposedly easy to master. I cannot even imagine the type of code many of our developers would write in C or C++.On 07-06-2012 00:04, J.Varghese wrote: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. JustinI'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). :)
Jun 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.
Jun 06 2012
no programming language will save you from thatLINQ isn't exactly susceptible to SQL injection. :P
Jun 06 2012
On 07-06-2012 07:04, Mehrdad wrote: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.orgno programming language will save you from thatLINQ isn't exactly susceptible to SQL injection. :P
Jun 06 2012
On Thursday, 7 June 2012 at 05:09:27 UTC, Alex Rønne Petersen wrote:On 07-06-2012 07:04, Mehrdad wrote: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.aspxLINQ can't mutate the state of the DB, only query it. LINQ far from covers everything.no programming language will save you from thatLINQ isn't exactly susceptible to SQL injection. :P
Jun 06 2012
On Thu, 07 Jun 2012 06:47:05 +0100, Mehrdad <wfunction hotmail.com> wrot= e:On Thursday, 7 June 2012 at 05:09:27 UTC, Alex R=F8nne Petersen wrote:=On 07-06-2012 07:04, Mehrdad wrote:LINQ can't mutate the state of the DB, only query it. LINQ far from =no programming language will save you from thatLINQ isn't exactly susceptible to SQL injection. :Pf =covers everything.True enough, although it's not too difficult to imagine an extension o=LINQ where that is indeed possible. Nonetheless, the following /is/ called "LINQ to SQL" (why, I don't kno=w):http://msdn.microsoft.com/en-us/library/bb386941.aspxI've done some work with LINQ to SQL recently. The reason that is label= ed = as such is that the DataContext object which is used in those examples i= s = one generated by the LINQ architecture from a SQL database. So, while = this has nothing to do with LINQ style statements in code, it is related= = to the objects those statements are used on/with. :) R -- = Using Opera's revolutionary email client: http://www.opera.com/mail/
Jun 07 2012
On Thursday, 7 June 2012 at 05:04:30 UTC, Mehrdad wrote:I would consider Linq to SQL more of a library than a language, even though it has compiler support. It's also something that especially if that __traits(codeof) pull gets added.no programming language will save you from thatLINQ isn't exactly susceptible to SQL injection. :P
Jun 06 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: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!I would consider Linq to SQL more of a library than a language, even though it has compiler support. It's also something that especially if that __traits(codeof) pull gets added.no programming language will save you from thatLINQ isn't exactly susceptible to SQL injection. :P
Jun 06 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
Jun 07 2012
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. -- PauloSo if the causes of most C and C++ security exploits have been addressed in D and D makes it difficult to write insecure code, what exploits are still possible in D? Have the most serious and numerous bugs been made unlikely in D? Does anybody know if D makes new classes of bugs possible? If I was comparing a C/C++ OS versus an identical OS written in D, do you have estimates for many fewer bugs the D OS will have? 20% fewer minor bugs? 50% fewer critical bugs? Is that even the right question to ask?
Jun 07 2012
On Thursday, 7 June 2012 at 09:44:35 UTC, J.Varghese wrote:If I was comparing a C/C++ OS versus an identical OS written in D, do you have estimates for many fewer bugs the D OS will have? 20% fewer minor bugs? 50% fewer critical bugs? Is that even the right question to ask?You should tell how many bugs in OSes are specific to C language level security.
Jun 07 2012
"J.Varghese" <unnecessary unknown.com> wrote in message news:vcmamxcuyhiqigjrqnxf forum.dlang.org...If I was comparing a C/C++ OS versus an identical OS written in D, do you have estimates for many fewer bugs the D OS will have? 20% fewer minor bugs? 50% fewer critical bugs? Is that even the right question to ask?It's not that predictable. It all depends on the code, the programmers, the way the project's managed, all sorts of very non-quantifiable things. There's a lot about D that makes it easier to write code that's less buggy, and less prone to certain security issues, etc., but it's not something that can really be quantified like that, regardless of what two languages you're comparing.
Jun 07 2012
It's not that predictable. It all depends on the code, the programmers, the way the project's managed, all sorts of very non-quantifiable things. There's a lot about D that makes it easier to write code that's less buggy, and less prone to certain security issues, etc., but it's not something that can really be quantified like that, regardless of what two languages you're comparing.Thanks. I understand better now.
Jun 08 2012
On 6/6/2012 3:04 PM, 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++?D offers a number of features designed to reduce and even eliminate security problems due to exploits of memory corruption issues. For example, safe functions. D does offer things like better encapsulation methods that enable the programmer to better define interfaces, such as contracts, but designing that for security would be entirely up to the programmer.
Jun 07 2012