www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Security Report on D (NET-255)

reply Gold Dragon <dragonwing dragonu.net> writes:
I was hoping you guys would write the report for me... there may be some money
involved.

I'm just kidding.

Actually, what I want is to know from the experience of people writing D how
you liked/disliked it.
Also I need to post questions since the only documentation is on the Mars D
site and Wiki D so I'm
kind of limited in articles and resources. There is a wealth of information on
both sites but I may
need some information not on the sites. Citation is going to be a bitch indeed.

The way I'm going to write the report is on the "unique" features that D has:

Design by Contract
Template Syntax
Built-in Garbage Collector
Others...

Perhaps also go into advantages/disavantages over .NET (there are some articles
already on newsgroup
that may help me).

Another topic that I have to do since it is a security class, is well,
security. How can you secure
D from hackers, reverse engineering (if it is possible), and how D can be used
to create viruses. I
could just half ass this topic depending on how much space I need to fill,
since most are applied to
most languages anyway.

Thanks,
Jacob Santos
Sep 16 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cibpov$2ejf$1 digitaldaemon.com>, Gold Dragon says...


How can you secure
D from hackers,


Please could you be more specific in your question. It's a little too vague to
be meaningful, right now.



reverse engineering (if it is possible),


Reverse engineering is /always/ possible, in any language.



and how D can be used to create viruses.


Even if I new the answer to that question, it would be highly irresponsible of
me to answer it.

Arcane Jill
Sep 16 2004
next sibling parent =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
Arcane Jill wrote:


 In article <cibpov$2ejf$1 digitaldaemon.com>, Gold Dragon says...



and how D can be used to create viruses.


 
 
 Even if I new the answer to that question, it would be highly irresponsible of
 me to answer it.


The answer isn't really that dangerous:

The same as any other high-level general-purpose language.

One could however argue that due to the footprint of any D program being 
considerably larger that the footprint of a hand-assembled one, it'd 
have a great deal more difficulty propagating and escaping detection.

And in the end, virii are caused by gargantuan architectural flaws in 
the security model used by most modern operating systems. That an 
executable should be capable to editing every file on the HD *just* 
because the logged-in user can is preposterous. It's fairly depressing 
there exists a market for anti-virus software.

Cheers,
Sigbjørn Lund Olsen
Sep 16 2004
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <cibvum$2ibb$1 digitaldaemon.com>, Arcane Jill says...

In article <cibpov$2ejf$1 digitaldaemon.com>, Gold Dragon says...


How can you secure D from hackers,


Please could you be more specific in your question. It's a little too vague to
be meaningful, right now.


The obvious issue that comes to mind is buffer overrun attacks (since they're
such a hot topic these days).  D has built-in support for dynamic arrays and
offers string.format (which can resize the buffer if needed) instead of sprintf,
both of which reduce the likelyhood that an average program will be written in
such a way that buffer attacks are possible (compared to C/C++).


Sean
Sep 16 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cic9hi$2oaa$1 digitaldaemon.com>, Sean Kelly says...

In article <cibvum$2ibb$1 digitaldaemon.com>, Arcane Jill says...

In article <cibpov$2ejf$1 digitaldaemon.com>, Gold Dragon says...


How can you secure D from hackers,


Please could you be more specific in your question. It's a little too vague to
be meaningful, right now.


The obvious issue that comes to mind is buffer overrun attacks (since they're
such a hot topic these days).  D has built-in support for dynamic arrays and
offers string.format (which can resize the buffer if needed) instead of sprintf,
both of which reduce the likelyhood that an average program will be written in
such a way that buffer attacks are possible (compared to C/C++).


Yes, I thought the original poster might have been referring to buffer overruns.
Well then, D allows you to write low-level code, with the potential for
low-level bugs. There is nothing to stop you, for example, calling the C
function gets() - (viola - instant bug; instant security hole!).

It could be argued that the only way to avoid buffer overruns is to use a
language which prohibits them, such as Java. However, just because D /allows/
you to write scary code, it doesn't /force/ you to do so. It's a systems
programming language, with all the risks and responsibilities that go with that.
Perhaps the bottom line is that if you're going to write a security app, you'd
better know what you're doing. D does not claim to protect you from your own
errors, and when it comes to security, every error is a potential hack-route.

Arcane Jill
Sep 16 2004
parent reply Rex Couture <Rex_member pathlink.com> writes:
In article <cie0th$ol8$1 digitaldaemon.com>, Arcane Jill says...

It could be argued that the only way to avoid buffer overruns is to use a
language which prohibits them, such as Java. However, just because D /allows/
you to write scary code, it doesn't /force/ you to do so.


Neither does C, but I'll bet just about every buffer overrun, every memory leak,
and every faulty commercial program was written in C or C++.  Somehow, these
programs always rear their ugly heads and threaten my data at crunch time.

I really think you're missing a fantastic opportunity here.  If I were to read
that a program were written in a nice, simple language that absolutely prevents
"scary" errors, I would definitely give it a second look.

For any critical use, if I had a choice, I wouldn't even consider a program that
had any possibility of memory violations.

Yes, I know, you say you don't have to use the scary features (but claim that
they are essential nonetheless).  That's not the point.  The point is that C
programmers like these and will probably use them.  Lacking strong evidence to
the contrary, from bitter experience I just assume that every program I buy is
full of such bugs.

If you must retain unsafe features in D, you could at least isolate them to an
unsafe system library.  If that library is not used, you could then certify the
program as safe.
Sep 17 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Rex Couture" <Rex_member pathlink.com> wrote in message
news:cif54l$23ig$1 digitaldaemon.com...

 Neither does C, but I'll bet just about every buffer overrun, every memory


leak,

 and every faulty commercial program was written in C or C++.  Somehow,


these

 programs always rear their ugly heads and threaten my data at crunch time.

 I really think you're missing a fantastic opportunity here.  If I were to


read

 that a program were written in a nice, simple language that absolutely


prevents

 "scary" errors, I would definitely give it a second look.


The difference here is that to prevent buffer overruns in C, *extra* work is
necessary on the part of the programmer. With D, one has to do extra work to
get a buffer overrun. This pattern is fairly consistent: while D maintains
the ability to use scary features, using them usually means the programmer
has to do extra work, whereas the C programmer has to do extra work to avoid
the problem.
Sep 17 2004
parent Rex Couture <Rex_member pathlink.com> writes:
In article <cif9iv$2c1g$1 digitaldaemon.com>, Walter says...

...With D, one has to do extra work to
get a buffer overrun. This pattern is fairly consistent: while D maintains
the ability to use scary features, using them usually means the programmer
has to do extra work....


Thanks.  That is a vast improvement.
Sep 17 2004
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <cif54l$23ig$1 digitaldaemon.com>, Rex Couture says...

Yes, I know, you say you don't have to use the scary features (but claim that
they are essential nonetheless).  That's not the point.  The point is that C
programmers like these and will probably use them.  Lacking strong evidence to
the contrary, from bitter experience I just assume that every program I buy is
full of such bugs.

If you must retain unsafe features in D, you could at least isolate them to an
unsafe system library.  If that library is not used, you could then certify the
program as safe.


D does array bounds checking, which is a significant step in the right
direction.  I'm pretty sure the only means to cause a buffer overrun in D is to
use pointers, which I expect to be quite uncommon in typical D programs.


Sean
Sep 17 2004
parent reply Rex Couture <Rex_member pathlink.com> writes:
In article <cifa5f$2d3u$1 digitaldaemon.com>, Sean Kelly says...

...which I expect to be quite uncommon in typical D programs.


I was hoping for something more like total erradication.  Arcane Jill just gave
us one simple scenario how such security holes will get in.  I'm confident that
someone somewhere is going to use some treacherous C code or do something
equally dumb.

D is a good start, but keep thinking security.  :-)
Sep 17 2004
parent Sean Kelly <sean f4.ca> writes:
In article <cifc0g$2gln$1 digitaldaemon.com>, Rex Couture says...

In article <cifa5f$2d3u$1 digitaldaemon.com>, Sean Kelly says...

...which I expect to be quite uncommon in typical D programs.


I was hoping for something more like total erradication.  Arcane Jill just gave
us one simple scenario how such security holes will get in.  I'm confident that
someone somewhere is going to use some treacherous C code or do something
equally dumb.

D is a good start, but keep thinking security.  :-)


Thing is, any systems programming language will let the programmer do all sorts
of evil things if he really wants to.  I think Walter's approach is the correct
one in that it makes such things a bit more complicated so such practices will
tend to be restricted to places where they're actually needed.  Needless to say,
the easiest way to prevent buffer overrun attacks is to use the code/data flags
provided by modern processors.  But then a clever systems programmer may want
his data segments executable :)


Sean
Sep 17 2004
prev sibling parent Gold Dragon <dragonwing dragonu.net> writes:
 The obvious issue that comes to mind is buffer overrun attacks (since they're
 such a hot topic these days).  D has built-in support for dynamic arrays and
 offers string.format (which can resize the buffer if needed) instead of
sprintf,
 both of which reduce the likelyhood that an average program will be written in
 such a way that buffer attacks are possible (compared to C/C++).


Thanks Sean,

The teacher was talking about buffer over runs and linux has them also. If
Linux could be remade in 
D then it would solve some problems. I doubt the likelyhood of that ever happen
but okay. It is an 
advantage of D that I can discuss either in the report or in the Presentation.
Sep 17 2004
prev sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
The way I'm going to write the report is on the "unique" features that D has:

Design by Contract
Template Syntax
Built-in Garbage Collector
Others...


Sorry, I don't get it.
Design by Contract isn't unique to D. Eiffel had id _LONG_ before D (IMHO that's
where D has "stolen" it from, but I'm only guessing, as there are so many
languages that have DbC built in, like Sather, ...).
A Garbage Collector isn't unique, too. Most languages actually have one.



Perhaps also go into advantages/disavantages over .NET (there are some articles
already on newsgroup
that may help me).


NET is a language independend platform, D is a language. So you compare two
things that have nothing in common. There actualy is a project called D.NET,
which brings D to .NET.

-- Matthias Becker
Sep 18 2004
parent reply Gold Dragon <dragonwing dragonu.net> writes:
I will reiterate and explain better what I'm trying to say. I'm comparing, C
and C++ when I speak of 
D as they are fairly close. The uniqueness is that neither have some of the
features builtin to the 
languages. I probably won't go into the history of languages that had the
features before because I 
feel it is outside the depth of the report. If I went into explaining which
languages had the 
features first and how they worked then I would have about a 30 paged report
(hyperbole but you see 
the point?).


wrote .NET so it was 

are fairly close, 
feature wise. I won't be comparing it to Java either, the teacher pretty much
hates the Microsoft so 
I can get some kiss-ass points from bashing poor, helpless Microsoft.

If you like, I can post the report to the newsgroup and you can correct any
mistakes I will make. It 
would help me out in editing the thing. My teacher isn't going to know enough
to correct any 
mistakes I make... but he also won't know that there were any mistakes. I'm not
the best writer so 
there will be grammar mistakes and some sentences will most likely suck but I
won't need help with 
that, at least not from here.

I should probably make this OT...

Jacob Santos


 Sorry, I don't get it.
 Design by Contract isn't unique to D. Eiffel had it _LONG_ before D (IMHO
that's
 where D has "stolen" it from, but I'm only guessing, as there are so many
 languages that have DbC built in, like Sather, ...).
 A Garbage Collector isn't unique, too. Most languages actually have one.
 
 
 

Perhaps also go into advantages/disavantages over .NET (there are some articles
already on newsgroup
that may help me).


 
 
 NET is a language independend platform, D is a language. So you compare two
 things that have nothing in common. There actualy is a project called D.NET,
 which brings D to .NET.
 
 -- Matthias Becker
Sep 20 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cing4v$44a$1 digitaldaemon.com>, Gold Dragon says...


If you like, I can post the report to the newsgroup and you can correct any
mistakes I will make. It 
would help me out in editing the thing. My teacher isn't going to know enough
to correct any 
mistakes I make... but he also won't know that there were any mistakes. I'm not
the best writer so 
there will be grammar mistakes and some sentences will most likely suck but I
won't need help with 
that, at least not from here.


Not wishing to sound rude, but it's generally considered bad practice to get a
newsgroup or forum to do your homework for you. I think we're all happy to help
out with opinions and information, but if you're gonig to get a better grade
than your classmates, it should be because /you/ did the work.

Jill
(Apologies if I was way off the mark - hope that wasn't too offensive).
Sep 21 2004
parent Gold Dragon <dragonwing dragonu.net> writes:
Nah, not to offensive and completely understood. Ha ha, ah damn.

I'm going to post back when I write the paper... which has to be soon. It would
be cool to get 
opinion on the thing because the people in class are zombies. Last report... ah
that story is for 
another time (Disclaimer: I'm never going to tell the story and I doubt that
anyone cares to hear it).


 Not wishing to sound rude, but it's generally considered bad practice to get a
 newsgroup or forum to do your homework for you. I think we're all happy to help
 out with opinions and information, but if you're gonig to get a better grade
 than your classmates, it should be because /you/ did the work.
 
 Jill
 (Apologies if I was way off the mark - hope that wasn't too offensive).
Sep 25 2004