In C++ world there is a variety of ways to make an exploitable vulnerability: buffer overflow, unsafe sting handling, various arithmetic tricks, printf issues, strings not ending with '\0' and many more. Despite most of these problems were solved in java, there are some things to talk about.
But is there any list of typical C#-specific coding vulnerabilities? (and not related to .NET platform itself)
Here are a few issues you can run into:
If you've got any sort of language interpreter (HTML, JavaScript, and SQL being the big three) then you can still have injection or XSS vulnerabilities.
P/Invoke can cause problems, especially if you're doing any custom marshalling. Even if you're calling a "safe" API through P/Invoke, your marshalling code could contain a bug that corrupts or exposes memory.
If you're doing file access then you need to make sure your files are always in acceptable directories. Be sure to sanitize against bad absolute and relative paths.
Cryptography. Good cryptographic programming is really hard, and .Net's various safety features do nothing against crypto attacks.
C# is based on .NET and .NET is supposed to be type-safe, which means none of your list of horrors applies to C# or any .NET language.
But then again, C# has an unsafe keyword and after that all bets are off.
It allows real pointers and everything that comes with them.
Not really. I'm going to make a bold statement here:
There's no such thing as a "C#-specific coding vulnerability that isn't related to the .net platform".
A program written in C++ is compiled directly into a machine executable, so the language compiler is directly responsible for the creation of the executed code, hence the way C++ can be easily capable of "creating an exploitable vulnerability".
A program written in C# however is compiled into IL, which is the only language that the .net platform works with. The .net environment creates a machine executable based on that IL code. Everything that C# can do is merely a subset of what the .net platform is capable of. This is how I can make my bold statement. Anything you could possibly do with C# that created a coding vulnerability would be one of:
1) A bug in the .net platform
or
2) Executing code outside of the .net platform
So the way your question is currently phrased leads me to believe that either you're not fully aware of the huge differences between "writing code in C" and "writing code for the .net platform" or I'm misunderstanding your question. Perhaps a bit of both! 8 )
Hope this helps!
Probably none from your list of concerns but this is the one to be careful with: void*
Don't forget, you can call any C++ from C#. I do it all the time. So all the buffer overrun issues and so on for C++ are relevant for C# as well even if you don't directly call C++ because C# calls C++ to do it's work.
Think about it. And any COM calls and Marshal calls are just as open to attack as normal. In Linux you can use _r routines and in Ver 8 up in VC++ you can use _s routines to lessen then chance of buffer overflow (requires user buffers and/or max sizes). About the only way to stop vulnerabilities is to turn off your computer and read a paper back book (unless it too has a virus).
Related
Is it true that the applications that are written in C++/CLI with /clr switch are more complicated for the crackers than C# applications? Does C++/CLI generate applications that are in general more complicated to disassembly and crack?
I know that it is a matter of the way that you are doing to code, but I am asking about the general case of difficulty that faces crackers.
If you're mixing native and managed code, yes it's more difficult, because they would be required to know x86 assembly to read your code. Still doable, but more difficult than pure managed code.
If you're compiling only managed code (which you can do in C++/CLI), it's all compiled down to MSIL and can be disassembled easily with .Net Reflector. Managed code is all the same when its compiled, it's fairly easy to reconstruct C# code (or F#, etc..) from managed C++/CLI code that's been compiled down to its MSIL form.
You're better off obfuscating your code, if you want it to be more difficult to crack.
Dotfuscator Community Edition is included with VS2010. That will change certain class, method, field and property names to random characters. More robust features are included in pay editions of these kinds of software, where it would actually change the program's structure a bit to make it even more difficult to read. There are other techniques to prevent disassembly, but they're too many to list here.
Side Note
That doesn't necessarily make your code secure. Say, for example, you're trying to impose usage limits on an application you wrote. Maybe you use a file in an obscure place and/or a registry key to keep track of how many times the program was used. You want to prevent the program from being used more than 30 times before they buy it. I could open up Process Monitor, load your program, find the file and registry key you keep track of this information and reset it each time I want to bypass your limits. That didn't require any cracking whatsoever.
Your security is only as good as you make it, decompiling isn't everything.
It's entirely possible, but I would like to stress that "difficult to disassemble" does not equate to "secure".
No code that you deliver to a third party, in any form, should be considered "secure". It's all crackable, and there's nothing you can do about it, so you'd be better off adopting a business model that doesn't rely on it.
In fact C# should be a bit safer against buffer overflows, which can be used to inject assembler code to the stack.
Or I should ask how helpful and benifitial will it be to start with C++
This may seem irelevant but it has some significance for me,may be few others like me.
I just want to know ,How Important is it to Learn C++ , COM and ATL while you are a .NET programmer?
I love programming with .NET and C# .Visual Studio just has it's own charm of intellisence ,Color Coding and other pretty features , which make us addicted to it.
I was thinking , almost we can build anything with C# and still it holds true mostly, but it lags sometimes like:
While I try to create a Shell Extension , then it is highly suggested to use unmanaged code instead of any managed code.
Also there are few other things like COM , ATL , which are preferred to be coded in C++ rather than C#.
I am just 4 years in IT industry and love to be Solution Architect.
So need all your inputs to know , how important/helpful will it be in my future venture if I am doing my Current COM Project with C++ , which integrate with .NET UI.
Is there any implementation of C++ and .NET in common domains like Health Care, Banking and Telecommunication.
The issue (at least for the specific cases you mention, such as shell extensions) with trying to "integrate with a .NET UI" is that you really can't. The reason it's not a good idea to write shell extensions in managed code is that a given process can only load one version of the CLR at any given time. If two shell extensions depend on different versions of the CLR, and they both try to load at the same time, it will fail. You can't load the CLR in any way shape or form in the context of your shell extension and be a well behaved shell extension.
My advice would be to not bother with C++ until you really have a reason to learn it (despite that C++ is my favorite language). But when you do learn C++, leave your .NET baggage at the door. There are lots of things (such as excessive use of casting, constantly using new, etc) which are idiomatic C#, and are just plain wrong in C++. You will be a lot happier if you don't try to understand C++ concepts in terms of the CLR -- simply because C++ doesn't run there. You can use some of the design patterns you may have learned for C#, but how the underlying language and machine operates are completely different between the two languages.
Probably the most confusing difference for new C or C++ programmers is the concept of undefined behavior. The C and C++ standards are written in such a mannar as to not be tied to a particular machine. This is in stark contrast to architectures like Java or .NET, where the language is actually defined in terms of a virtual machine (and therefore is extremely dependent on that VM). This leads to places where the standard literally does not say what the correct output of a program should be; and instead says "however the underlying machine usually does this". You'll probably notice this quite a bit if you're ever dealing with floating point math. While C# has strict and specific rules about how and where floating points are calculated and rounded, C and C++ make no such qualifications.
Once you understand C++, then you can move on to COM and ATL. COM is essentially designed to make a C++ like class structure accessible in a language (the COM ABI), machine (marshalling between 32 bit and 64 processes on the same system, etc), and location (DCOM provides RPC facilities) independent way. If you don't understand the C++ object model, then you're going to have an extremely difficult time with the COM object model, because the two are extremely similar. ATL is a set of C++ class templates around COM fundamentals which simply handle some of the boilerplate for you.
I just want to know ,How Important is
it to Learn C++ , COM and ATL while
you are a .NET programmer?
Depends what you do. You are way better of learnin about databases. Pretty much every serious app uses a database.
But C++ IS ued together with .NET - especially C++/CLI (the managed variant) as it is very good for integrating C++ code with managed code effficiently. Quite often pretty much the only efficient way. Which is important if you for example raise events for market data. With a frequency in excess of 100.000 times. Per second.
But this is a NICHE. I work in the financial area, and tthe C++ uses AND integration uses are SMALL compared to the people working in .NET / In the application.
C++ and C# are quite simmilar programming languages, in my opinion. If a C++ code needs to be ported to platform where C# is the only supported platform, how much work will need to be done?
Should I get ready, that most of the C++ code will need to be rewritten to C#? Or, because of language simmilarities, should refactoring be quite easy and straightforward?
I am aware, that it will depend on the application itself, but I am asking in general.
I have done a major port of a C++ application to C# recently. Overall I thought it was a pleasant experience. These are the steps that I took, they might or might not apply to your application.
Get the "scaffolding" in place in C#, design your architecture. This is the time to get in major architecture changes from the existing application if you choose to do so.
Get your tests in place. I can't over-emphasize this one. Since you are porting an existing application you should have a set of tests already in place that verify the correct behavior of your application. You can and should reuse these tests for your C# application. This is the one thing that gives you an edge when porting - you know (and have written) already many of the tests you want. Start porting your test project.
Put in method stubs for your C# methods that reflect the existing C++ methods. Given the framework support in C# some methods might not be needed at all anymore, or are very simplified - this is the time to decide.
Copy and paste. Yes I used copy and paste for most of the C++ code - all the flow statements basically can be reused if you are careful. Once pasted go through line by line, many things like use of pointers etc. must be rewritten to use a equivalent C# type.
Once you have re-written a method in such a way, do the obvious re-factoring given the framework support / helper classes you might have been lacking in C++ but are readily available in C#. Also naming conventions for variables etc. can be changed here, should be straightforward given the built in support for this in VS 2010.
Run your tests! Test early and often that the overall framework you have in place so far produces the exact same output as your C++ application which you can use as a reference. This is also the time to add missing tests.
Refactor, Refactor, Refactor. Every application ages, and so did your C++ application most likely. Look closely at the underlying design and simplify and remove as much as possible. Verify at each step by running your tests.
First thing first, this is porting and not refactoring. Also I think it's an extremely bad idea.
It is true that you could (with a lot of work) port C++ to unsafe C#, but saying that the syntax is very similar is a bit of a stretch. In fact, following the same line of reasoning you could port C++ to any other C derived language, and it would be equally painful.
Again, if you do it expect a shedload of rework. It's more than likely gonna take you more than re-coding it from scratch using the existing code as mere model, which is in my opinion a better and less messy option.
Just compile the C++ code with the /clr compiler option. That will translate the code to IL, it can execute on most any .NET enabled platform. There are very few C++ constructs that cannot be translated, it would have to use non-standard compiler extensions like __fastcall.
However, I suspect that you will find out that the platform requires verifiable code. Which is the common reason why a platform would restrict code to a .NET compliant language. I cannot guess at this since you didn't mention the execution environment. Native C++ translated to IL is not verifiable due to pointer manipulations. If that's the case then you are looking at a pretty drastic rewrite.
I'd be interested to know where C# is the "only supported platform".
The problem of rewriting in a new language can be whether you need to rewrite every single part of the code and cannot use any of the old code at all. Sometimes it is best, even when doing a rewrite, to make it more of a refactor: rewrite some parts of the code, move others. The existing code is known to work and can be tricky to reproduce. And it takes time. There needs to be a good reason to do a full rewrite.
.NET supports a version of C++, and Visual Studio also comes with Visual C++ to build standard C++, so consider whether or not you can make this a phased transformation, and whether or not you really have to rewrite the whole thing.
Porting C++ code to C# will not be that hard, assuming that all your dependent libraries have existing C# counterparts. Lack of dependencies is the most likely pitfall. The core concepts of your program, such as inheritance, heap, references, data structures, should be fairly easily translatable.
This is assuming that you don't invoke any specific low level behaviour such as custom memory management, because C# does not really support that kind of thing and you could have a serious problem there.
I have some old C 32 Bit DLLs that are using Oracle's Pro C precompiler library (proc.exe) to expose a hundred or so sproc/func calls to an even older VB6 GUI which references these functions through explicit Declare statements like so:
Declare Function ConnectToDB Lib "C:\windows\system32\EXTRACT32.DLL" (CXN As CXNdets, ERR As ERRdets) As Long
All the structures in the C header files are painstakingly replicated in the VB6 front end. At least the SQL is precompiled.
My question is, is it worth trying to impose a .Net interface (by conversion to an assembly) onto the the C code and upgrade the VB6 to C# or do you think I should just abandon the whole thing and start from scratch. As always, time is of the essence hence my appeal for prior experience. I know that if I keep the Declares in .Net I will have to add lots of complicated marshalling decorations which I'd like to avoid.
I've never had to Convert C to .Net before so my main question if everything else is ignored is are there any porting limitations that make this inadvisable?
... At least the SQL is precompiled.
Is this the only reason you've got code in C? If so, my advice is to abandon that and simply rewrite the entire thing in C# (or even VB6 if that's what your app is written in) ... unless you've profiled it and can prove a measurable difference, you won't be getting any perf benefits from having sql/sproc calls in C. You will only get increased maintenance costs due to the complexity of having to maintain this interop bridge.
You should continue to use the DLL in .NET by creating an assembly around the Declares. That one assembly probably would go a little quicker in VB.NET than C#. Then have your new UI reference that assembly. Once you have that going then you have bought yourself time to convert the C code into .NET. You do this by initially keeping the assembly and replacing the the declares with new .NET code. Soon you will have replaced everything and can refactor it to a different design.
The time killer is breaking behavior. The closer you can preserve the behavior of the original application the faster the conversion will be. Remember there nothing wrong with referencing a traditional DLL. .NET is built on many layers of APIs which ultimately drill down to the traditional DLLs that continue to be used by Windows. Again once you have the .NET UI working then you have more time to work on the core and bring everything into .NET.
I always advise extreme caution before setting out to rewrite anything. If you use a decent tool to upgrade the VB6 to .NET, it will convert the Declare statements automatically, so don't stress about them too much!
It's a common pitfall to start out optimistically rewriting a large piece of software, make good early progress fixing some of the well-known flaws in the old architecture, and then get bogged down in the functionality that you've just been taking for granted for years. At this point your management begin to get twitchy and everything can get very uncomfortable. I have been there and it's no fun. Sounds like your users are already twitchy, which is a bad sign.
...and here's a blog post by a Microsofty that agrees with me:
Many companies I worked with in the early days of .NET looked first at rewriting driven in part by a strong desire to improve the underlying architecture and code structures at the same time as they moved to .NET. Unfortunately many of those projects ran into difficulty and several were never completed. The problem they were trying to solve was too large
...and some official advice from Microsoft UK regarding migrating from VB6 to .NET
Performing a complete rewrite to .NET is far more costly and difficult to do well [than converting] ... we would only recommend this approach for a small number of situations.
Maybe your program is small, and you have a great understanding of the problems it solves, and you are great at estimating accurately and keeping your projects on track, and it will all be fine.
If you move from VB6 to VB.net or C#, throw away the C code and use the appropriate ODP.net classes or LINQ to access those stored procedures. Since the C layer (as I understand it) has no logic other than exposing the stored procedures, it's not useful anymore after the switch. By doing that, you get (at least) much better exception handling (i.e. exceptions at all instead of magic return codes), maintainability etc.
See also: Automatically create C# wrapper classes around stored procedures
What can be done in VC++ (native) that can't be done with VC#?
From what I can tell the only thing worth using VC++ native for is when you need to manage memory yourself instead of the CLR garbage collector, which I haven't seen a purpose in doing either (but thats for another question to be asked later).
Cross-platform development. Yes Mono exists, and Java's somewhat more predictable to have it function EXACTLY the same on more platforms, you can find a C/C++ compiler for just about any platform out there, where you can't with C#.
Also linking into 3rd-party libraries, while I'm sure there's a way to leverage them in C#, you'll be able to take advantage of them without interop (Marshaling, etc) in C++.
Edit: one last thing: RELIABLE memory management. Yes you can use dispose(), and try-finally, but there's nothing quite like KNOWING the memory is gone when it's popped off of the stack. Through techniques like RAII, when you use well-constructed classes, you will KNOW when your classes release resources, and not waiting around for the GC to happen.
With P/Invoke there is very little that is impossible in .NET (most obviously device drivers).
There are also things where the advice is to not use .NET (e.g. shell extensions, which get loaded into any process that opens a file dialogue1).
Finally there are things which will be much harder in .NET, if possible at all (e.g. creating a COM component that aggregates the FTM).
1 This can create a problem if that process is already using a different version of .NET. This should be alleviated in the future with .NET 4 having the ability to support side by side instances of the runtime.
I'm not sure if you're talking about language features or applications. My answer though is for applications / components.
Really there are only 2 things you cannot do in C# that you can do in C++.
You cannot use C#, or any other .Net language, to write a component for a system that only accepts native components
You cannot use C#, or any other .Net language, to alter certain properties of a CCW for which the CLR does not allow customization
The most notable item here is Device Drivers. This is a framework that only accepts native components and there is no way to plug in a managed component.
For everything else it's possible to do the same thing in C# as it is in C++. There are just a lot of cases where you simply don't want to and a native solution is better. It's possible for instance to manage and manipulate memory in C# via unsafe code or IntPtr. It's just not nearly as easy and generally there's no reason.
You can't write device drivers for one.
I think there are several important points:
You can do anything in C#/C++/Java/Python/Lisp or almost any other language, finally all of them Turing complete ;)... The question is it suits your needs?
There is one big and extreamly important limitation of C#... It runs only one single platform Windows... (Mono is still not mature enough).
There are many applications where GC is just a waste of resources, applications that can't afford you throw up 1/2 of memory untill next gc cycle: Games, Data Bases, Video auido Processing and many other mission critical applications.
Real Time applications (again games, video processing and so on). Non-deterministic GC makes life much harder for them.
In fact, most of desktop applications: Web Browsers, Word Processors, Desktop Environment itself (like Windows Explorer, KDE or Gnome) are written in compiled languages with careful thinking about resources... Otherwise, they would just be terrible bloated applications.
Whereas writing shell extensions in Windows XP was possible in C# it is next to impossible to write shell extensions for Vista and Windows 7. Shell extensions and Namespace extensions (and anything else that uses the new Properties system) (kindof) must be done in C++ unless you're into pain.
There are two obvious answers:
VC# can never run without the .NET
framework. Native C++ can. That may
be necessary in some areas (others
have mentioned device drivers, but
more common examples might simply be
clients where the .NET framework is
not installed. Perhaps you're
distributing an application and you
know not all of your customers are
willing to install .NET, so your
sales would go up if you made an app
that just worked without the
dependency on .NET. Or perhaps you're
working on some mobile device where
the couple of megabytes taken up by
the .NET CF can not be justified. Or shell extensions where using .NET can cause nasty problem for the user.
And VC# can never use C++ language
features. Native C++ can. (Managed
C++ can too, of course, but that's a
different issue). There are, believe it or not, things that can be done more conveniently or elegantly in C++. And they're only accessible if you're programming in C++.
System calls are no problem, however. p/invoke lets you do those from C#, almost as easily as you could from C++.
inline assembler
You cannot use C++-Libraries with classes (P/Invoke can only be used for functions AFAIK)
You cannot use callbacks with P/Invoke.
Is C# in particular and .NET in general self compiling yet (this is not a troll, I genuinely don't know)? If not, you can use VC++ to write C# and .NET, but you can't use C# to do the same job.
This is tongue in cheek, but it also is an answer to your question... you can screw things up much more severely in VC++ than you can in VC#. Not that you can't manage to screw things up severely in VC#, but in general, you can screw them up easier and more thoroughly in VC++.
Again, kind of tongue in cheek, but also an answer to your question. Perhaps not what you were hoping for, but... :-)
There's also hard real-time applications. Any language with a GC cannot be used, just in case it decides to collect during a time-constrained part of the code. Java was notorious for not even allowing you to try (hence the EULA about not using it for software "intended for use in the design, construction, operation or maintenance of any nuclear facility"
(yes, I know they've since made a modified version of Java for real time systems).
For example, it makes sense to use C++ if it's harder to translate the header files for existing libraries than it is to give up the existing managed libraries.
The Main difference is:
C++ is a core language with which you can build stand-alone programs. These Programs communicate directly with the the operating system and nothing else. C++ compilers exist for more or less all platforms (operating systems).
C# is a language that conforms to the CLS. A program written in C# can not start without a CLI engine (.NET Framework, Mono, etc.). A Program written in C# communicates with the .NET framework AND with the operating system. You have a man in the middle. Like all servicing personal, this man can help but it will cause additional trouble. If you want to port, you have a different man in the middle etc. CLI Implementations do not exist for all platforms.
By my opinion every additional framework is a additional source of problems.
Using SSE instructions seems to be one of these cases. Some .NET runtimes will use some SSE instructions, depending on your code. But in VC++, you can use the SSE intrinsics directly. So, if you're writing a multimedia code, you'd probably want C++. (C++/CLI might work as well, presumably)