Is C# secure ???

[David McManamon]

I am a Java programmer and a co-worker says I should check out this language.
At first glance it seems C# and Java offer basically the same language features
which have some huge advantages over C++. Seems C# will faces some serious
problems since security (the lack of) will become a big issue if people start
to actually use the language, portability doesn't seem like it will occur
anytime soon and most importantly C# is already 5 years behind the Java lifecycle
of deployment, users, robustnuss, API, security, etc. Why would anyone switch
to C# just to be able to write get() set() routines with a few fewer lines
?? From my biased point of view it seems that Microsoft lost the court case
against SUN and is scrambling for a way to stay king of the proprietary code/OS
hill.

David

[Eric Gunnerson]

I'm confused.

In what way do you think that C# isn't secure? There is a security model in
the runtime.

"David McManamon" <dmcmanam@hotmail.com> wrote in message
news:3a6df2b5$1@news.devx.com...
>
> I am a Java programmer and a co-worker says I should check out this
language.
> At first glance it seems C# and Java offer basically the same language
features
> which have some huge advantages over C++. Seems C# will faces some
serious
> problems since security (the lack of) will become a big issue if people
start
> to actually use the language, portability doesn't seem like it will occur
> anytime soon and most importantly C# is already 5 years behind the Java
lifecycle
> of deployment, users, robustnuss, API, security, etc. Why would anyone
switch
> to C# just to be able to write get() set() routines with a few fewer lines
> ?? From my biased point of view it seems that Microsoft lost the court
case
> against SUN and is scrambling for a way to stay king of the proprietary
code/OS
> hill.
>
> David

[Vlad Ivanov]

Everyone and their grandmother is refering to IL being on display.
Is it going to be like that? Or it will be encrypted (with performance loss
to decrypt it)?

"Eric Gunnerson" <ericgu@no.spam.microsoft.com> wrote in message
news:3a6f1c41$1@news.devx.com...
> I'm confused.
>
> In what way do you think that C# isn't secure? There is a security model
in
> the runtime.
>
> "David McManamon" <dmcmanam@hotmail.com> wrote in message
> news:3a6df2b5$1@news.devx.com...
> >
> > I am a Java programmer and a co-worker says I should check out this
> language.
> > At first glance it seems C# and Java offer basically the same language
> features
> > which have some huge advantages over C++. Seems C# will faces some
> serious
> > problems since security (the lack of) will become a big issue if people
> start
> > to actually use the language, portability doesn't seem like it will
occur
> > anytime soon and most importantly C# is already 5 years behind the Java
> lifecycle
> > of deployment, users, robustnuss, API, security, etc. Why would anyone
> switch
> > to C# just to be able to write get() set() routines with a few fewer
lines
> > ?? From my biased point of view it seems that Microsoft lost the court
> case
> > against SUN and is scrambling for a way to stay king of the proprietary
> code/OS
> > hill.
> >
> > David
>
>

[Jeff Peil]

"Vlad Ivanov" <vivanov@polarisconsulting.com> wrote in message
news:3a6f33fd$3@news.devx.com...
> Everyone and their grandmother is refering to IL being on display.
> Is it going to be like that? Or it will be encrypted (with performance
loss
> to decrypt it)?

That type of encryption would be worthless as the client machine executing
the code would need the key to decrypt, and thus someone who wanted to
decrypt could do so easily, once they determined where the key was stored.

Obfuscation OTH can help some (though, I generally consider the downsides to
obfuscation to make it an unappealing approach.)

[Vlad Ivanov]

It will most like be done with one way change of all the meaningful names
(vars, functions) into a guid-looking thingies. I dunno. I just don't really
give a crap about piracy - if i catch someone doing to me - i just wreck
their car and **** on their porch.


"Jeff Peil" <jpeil@bigfoot.com> wrote in message
news:3a6f402f$1@news.devx.com...
>
> "Vlad Ivanov" <vivanov@polarisconsulting.com> wrote in message
> news:3a6f33fd$3@news.devx.com...
> > Everyone and their grandmother is refering to IL being on display.
> > Is it going to be like that? Or it will be encrypted (with performance
> loss
> > to decrypt it)?
>
> That type of encryption would be worthless as the client machine executing
> the code would need the key to decrypt, and thus someone who wanted to
> decrypt could do so easily, once they determined where the key was stored.
>
> Obfuscation OTH can help some (though, I generally consider the downsides
to
> obfuscation to make it an unappealing approach.)
>
>
>

[Jeff Peil]

"Vlad Ivanov" <vivanov@polarisconsulting.com> wrote in message
news:3a6f43eb$1@news.devx.com...
> It will most like be done with one way change of all the meaningful names
> (vars, functions) into a guid-looking thingies. I dunno. I just don't
really
> give a crap about piracy - if i catch someone doing to me - i just wreck
> their car and **** on their porch.

Vlad,

What you are describing is obfuscation, not encyption.

[David Bayley]

Jeff,

> Obfuscation OTH can help some (though, I generally consider the downsides
to
> obfuscation to make it an unappealing approach.)

I know this is OT for the thread, but since Vlad raised it...

I have no experience of obfuscators, and have heard a few people slam them.
AFAICT, an obfuscator would firstly mangle all the private member names.
This raises the barrier to reverse-engineering, with no loss in performance,
by simply requiring the internals to be "reverse-named" as well... a good
thing.

Secondly, it can mangle some algorithms so that they work the same way, just
not very sensibly when it comes to maintainable code. The performance hit
from this obfuscation is pretty variable depending on the level of mangling
taking place, but I would imagine that an obfuscator would provide options
to control this. Again, the barrier to reverse-engineering is raised even
further, and hopefully to a level where "it ain't worth it" for the
competitor. (A determined hacker can still do there worse, just as they can
with assembly code, but that's not the point of using an obfuscator IMO.)

Just wondering, what other downsides do you see that make it unappealing?

--
David.

[Jeff Peil]

"David Bayley" <dbayley@aebacus.com> wrote in message
news:3a6f5414@news.devx.com...
> I have no experience of obfuscators, and have heard a few people slam
them.
> AFAICT, an obfuscator would firstly mangle all the private member names.
> This raises the barrier to reverse-engineering, with no loss in
performance,
> by simply requiring the internals to be "reverse-named" as well... a good
> thing.

The silent penalty is that obfuscators themselves cannot be aware of things
like reflection, and in being blind they can break internals that rely on
reflection. Thus, for example, if some of your code is relying on late
binding, an obfuscator can silently break it.

The other side of this coin is, consider a large block of source code, now
strip away all comments and documentation on that code (including the names
of variables local to functions, but leaving function names in place.) Then
try to decipher that code. If the code base is significant enough to
warrant concern, odds are that the code base is large enough that completely
reverse engineering the codebase is impractical.

So then we have to consider, how much more difficult does obfuscation make
stealing the "interesting" parts of the application (algorithms, ...) IMO,
obfuscation does not provide much protection against tracking down these
bits, and thus you pay a penalty for obfuscation with a low yield (as a
large app isn't likely to be cost-effective to reverse engineer regardless
of your usage of an obfuscator.)

> Secondly, it can mangle some algorithms so that they work the same way,
just
> not very sensibly when it comes to maintainable code. The performance hit
> from this obfuscation is pretty variable depending on the level of
mangling
> taking place, but I would imagine that an obfuscator would provide options
> to control this. Again, the barrier to reverse-engineering is raised even
> further, and hopefully to a level where "it ain't worth it" for the
> competitor. (A determined hacker can still do there worse, just as they
can
> with assembly code, but that's not the point of using an obfuscator IMO.)

Name mangling should have almost no runtime perf hit (as the token lookup
tables wouldn't be affected substantially.) Some obfuscators go beyond name
mangling, and reorder/rewrite the instructions to make it "harder" to
determine what the code is supposed to do. Generally this is a somewhat
effective technique against decompilers, but not against people seeking to
reverse engineer. The penalty with this approach is that it is far more
likely to find problems with the JIT (as the majority of the code the JIT is
tested against is generated by traditional compilers, there is a good chance
the JIT will either be less efficient with the instructions chosen by the
obfuscator, or in some cases the JIT may generate code that does not behave
appropriately at all.)

> Just wondering, what other downsides do you see that make it unappealing?

It's not so much that I think the downsides are significant, as it is that I
think the upsides are insignificant. I don't think that the benefits of
obfuscation generally justify the downsides.

[Vlad Ivanov]

Reading this with interest.

I am still wondering - so how does MS approach this?

On the subject of obfuscators that i brought up - i meant obfuscation of IL,
not original sourcecode. I didn't really think hard yet, to analyze what
problems might arise out of this. But runtime "late bound" reflection comes
to mind. Even if that does not happen - the decompile problem exists - if
JIT-runtime can determine how to handle obfuscated code - then a tool can be
written that does so as well.

So how does MS approach this?

Because if you think about it - nothing is stopping a really good hacker to
write his own IL debug environment - where he can even set breakpoints

> It's not so much that I think the downsides are significant, as it is that
I
> think the upsides are insignificant. I don't think that the benefits of
> obfuscation generally justify the downsides.
>
>
>

[Jeff Peil]

"Vlad Ivanov" <vivanov@polarisconsulting.com> wrote in message
news:3a6f6064$1@news.devx.com...
> I am still wondering - so how does MS approach this?

I don't think there is a clear answer today, however Ronald Laeremans has
said that mechanisms are being investigated.

> On the subject of obfuscators that i brought up - i meant obfuscation of
IL,
> not original sourcecode. I didn't really think hard yet, to analyze what
> problems might arise out of this. But runtime "late bound" reflection
comes
> to mind. Even if that does not happen - the decompile problem exists - if
> JIT-runtime can determine how to handle obfuscated code - then a tool can
be
> written that does so as well.

A person can also still reverse engineer it manually. The obfuscated code
is still valid MSIL the obfuscator merely tries to make things less obvious
(a for loop when emitted to msil generally has a consistent structure, an
obfuscator can translate it to a different set of MSIL instructions that
have the same net result making a decompiler's job of detecting the original
construct harder.) It's not an incredibly effective approach imo, as it
will just lead to the next generation of decompilers being equipped to
handle the constructs emitted by the obfuscator.

> Because if you think about it - nothing is stopping a really good hacker
to
> write his own IL debug environment - where he can even set breakpoints

Right, and the same applies to x86 code. Compiled code may be less easy to
read than source code, and obfuscated code may be more difficult to read
than code emitted by a compiler, but as long as the code is on the machine,
reverse engineering is certainly possible.

Again I would suggest you consdier taking a program with a large codebase,
strip out all comments and all local variable names (leaving you with
something still more informative than MSIL), and try to get a good
understanding of the code.

PostgreSQL and GCC are both good examples. Heck even if you leave the
comments in place, without using any docs outside the source code,
understanding a large codebase is not a trivial task.

[Eric Gunnerson]

Ah.

I thought you meant "security" in the "code can't format the hard drive"
sense, not "security" in the IP sense.

IP protection is something we're currently looking at, but we haven't
announced anything. We understand that some customers don't their code to be
easily decompiled.

"Vlad Ivanov" <vivanov@polarisconsulting.com> wrote in message
news:3a6f33fd$3@news.devx.com...
> Everyone and their grandmother is refering to IL being on display.
> Is it going to be like that? Or it will be encrypted (with performance
loss
> to decrypt it)?
>
> "Eric Gunnerson" <ericgu@no.spam.microsoft.com> wrote in message
> news:3a6f1c41$1@news.devx.com...
> > I'm confused.
> >
> > In what way do you think that C# isn't secure? There is a security model
> in
> > the runtime.
> >
> > "David McManamon" <dmcmanam@hotmail.com> wrote in message
> > news:3a6df2b5$1@news.devx.com...
> > >
> > > I am a Java programmer and a co-worker says I should check out this
> > language.
> > > At first glance it seems C# and Java offer basically the same
language
> > features
> > > which have some huge advantages over C++. Seems C# will faces some
> > serious
> > > problems since security (the lack of) will become a big issue if
people
> > start
> > > to actually use the language, portability doesn't seem like it will
> occur
> > > anytime soon and most importantly C# is already 5 years behind the
Java
> > lifecycle
> > > of deployment, users, robustnuss, API, security, etc. Why would
anyone
> > switch
> > > to C# just to be able to write get() set() routines with a few fewer
> lines
> > > ?? From my biased point of view it seems that Microsoft lost the
court
> > case
> > > against SUN and is scrambling for a way to stay king of the
proprietary
> > code/OS
> > > hill.
> > >
> > > David
> >
> >
>
>

[Krishna Moorthy]

First i would like to say that i am not a microsoft guy. I do hate the way
they work. But don't always see something through a mask. I recently attended
a one day seminar on C# and .NET, it sounds really neat.

Please read the Articles from Microsoft on C# and attend Seminars to know
about the latest technology and write your comments on C#.

My humble request is, please don't confuse the users just because you have
a hate towards microsoft.

Do Reply

Regards

R.Krishna Moorthy
Bangalore, India.



"David McManamon" <dmcmanam@hotmail.com> wrote:
>
>I am a Java programmer and a co-worker says I should check out this language.
> At first glance it seems C# and Java offer basically the same language
features
>which have some huge advantages over C++. Seems C# will faces some serious
>problems since security (the lack of) will become a big issue if people
start
>to actually use the language, portability doesn't seem like it will occur
>anytime soon and most importantly C# is already 5 years behind the Java
lifecycle
>of deployment, users, robustnuss, API, security, etc. Why would anyone
switch
>to C# just to be able to write get() set() routines with a few fewer lines
>?? From my biased point of view it seems that Microsoft lost the court
case
>against SUN and is scrambling for a way to stay king of the proprietary
code/OS
>hill.
>
>David

[nash]

Is there any software with 100% security? No way. Human makes the software,
human makes the hardware.Every software has its own security issues. Microsoft
became a giant company, so people all over world start cracking and find
the issues. If all people start doing the same at other softwares, then result
will be the same.

Its a product from Microsoft. Security issues will be reduced in next years.


C-Sharp has lot of advantages. Use them.

--------
n_vsnet
--------


"Eric Gunnerson" <ericgu@no.spam.microsoft.com> wrote:
>I'm confused.
>
>In what way do you think that C# isn't secure? There is a security model
in
>the runtime.
>
>"David McManamon" <dmcmanam@hotmail.com> wrote in message
>news:3a6df2b5$1@news.devx.com...
>>
>> I am a Java programmer and a co-worker says I should check out this
>language.
>> At first glance it seems C# and Java offer basically the same language
>features
>> which have some huge advantages over C++. Seems C# will faces some
>serious
>> problems since security (the lack of) will become a big issue if people
>start
>> to actually use the language, portability doesn't seem like it will occur
>> anytime soon and most importantly C# is already 5 years behind the Java
>lifecycle
>> of deployment, users, robustnuss, API, security, etc. Why would anyone
>switch
>> to C# just to be able to write get() set() routines with a few fewer lines
>> ?? From my biased point of view it seems that Microsoft lost the court
>case
>> against SUN and is scrambling for a way to stay king of the proprietary
>code/OS
>> hill.
>>
>> David
>
>

[ceemar]

I wish MS would've stuck around and fought for VJ++... 6.0 is really intuitive
and a blast to use.

Even tho C# comes from J++, from what I've seen I really don't care for it
due to the pointers and some of the other stuff from C++.

Then again I only do this stuff as a hobby so there might be some benefits
I'm missing.

"David McManamon" <dmcmanam@hotmail.com> wrote:
>
>I am a Java programmer and a co-worker says I should check out this language.
> At first glance it seems C# and Java offer basically the same language
features
>which have some huge advantages over C++. Seems C# will faces some serious
>problems since security (the lack of) will become a big issue if people
start
>to actually use the language, portability doesn't seem like it will occur
>anytime soon and most importantly C# is already 5 years behind the Java
lifecycle
>of deployment, users, robustnuss, API, security, etc. Why would anyone
switch
>to C# just to be able to write get() set() routines with a few fewer lines
>?? From my biased point of view it seems that Microsoft lost the court
case
>against SUN and is scrambling for a way to stay king of the proprietary
code/OS
>hill.
>
>David

[Vlad Ivanov]

"ceemar" <cemar@hotmail.com> wrote in message
news:3a75afae$1@news.devx.com...
>

> Even tho C# comes from J++, from what I've seen I really don't care for it
> due to the pointers and some of the other stuff from C++.


Then again, it might be useful to read the language spec. before saying
nonsense

No offense intended, just being cheerfully rude

P.S: If you didn't read it yet, there're no pointers in C# (in C++ sense),
there are delegates.