This all started innocently. I've been using the excellent version 6 of NetBeans as my primary IDE for a while now. Have been doing so since the beta releases. Since Java is now my primary platform. I use it for Java, Groovy, JRuby and even C++. I also have the Microsoft Platform SDK hooked in so I can pretty much do all my Win32 C++ work from there also.
The NetBeans project claims NetBeans is the only IDE you need. Well, not quite, if you're looking into .Net for example, NetBeans is a dud. Not that you couldn't write plugins to support it but that seems unlikely. I was really interested in looking into .Net, well .Net Compact more precisely.
I have no commercial interests in .Net, I like my solutions, all jokes aside, to be portable. The compact edition of the framework however is something I find truly irresistible compared to the Java ME headache.
If you want to test drive .Net, you're in luck, you can just download a copy of Visual Studio Express from here and incur away. I've been having quite a bit of fun with Visual C# Express 2008. If you want to try .Net Compact however, well the express editions don't do compact. What to do? Both Visual Studio 2005 and 2008 offer a trial version available from here and here respectively and this is what I used initially.
Both these products have restricted licenses and I started looking for an IDE project that would work directly on the top of the .Net SDK. I wasn't expecting much really but I was simply shocked when I found out about SharpDevelop.
A very, very good clone of the Visual Studio IDE. It doesn't support C++ but it supports Boo, Visual Basic, C# and has a new IronPython plugin. This IDE is really good. It could even teach NetBeans a few tricks or two. For example, the visual form designer in SharpDevelop works with all the supported languages, not just C#. Compared this to Project Matisse who only works with Java, and according to this blog entry at least, getting it to work on other languages will be difficult.
What does all of this have to do with this blog entry? Well, when I was initially surveying the SharpDevelop web site, the requirements for the product caught my eye. Namely, SharpDevelop doesn't require the .Net SDK, only the .Net runtime.
OK, since SharpDevelop works out of the box with Boo on Windows, then we can conjecture that SharpDevelop ships a copy of Boo. Correct.
OK, since SharpDevelop works out of the box with C# and Visual Basic on Windows, then we can conjecture that SharpDevelop ships a copy of the C# and VB compilers from Mono. Incorrect.
Process Explorer put this to bed very quickly. SharpDevelop was using "csc.exe" for compiling. I never installed the .Net SDK on this machine, where did it come from? Well, it turns out that, just like Java, the compiler is available from .Net as a service. Unlike Java however, the compiler executables for C# and VB actually ship with the .Net runtime. If you look in "C:\Windows\Microsoft.Net", you'll find that you have a folder in there for each version of the .Net runtime you have installed. You'll also find compilers for C# and VB inside those folders. This means that on a fully patched Windows Vista system running .Net 3.5, a user has 6 compilers installed, a C# compiler version 1, 2 and 3 and VB compiler version 7, 8 and 9.
For an old UNIX war horse like me, it's tough to see all these compilers. A long time ago, it was common practice to make sure all compilers were disabled on UNIX servers. So, if you had an attacker using say FreeBSD version 2 attacking a server running IRIX or HPUX, the attacker could not upload a C source of a password cracker to the system, compile it and run it. It was uncommon that an attacker would go to the trouble of setting up a cross compiler just to attack a server.
The popularity of Linux and/or Perl "fixed" that problem. Both systems now just run Linux on Intel and at one point, most UNIX systems started shipping Perl out of the box around version 4 of the interpreter. Disabling the compiler isn't as important has it used to be. Using the noexec bit on the file system is obviously more important than ever.
We can make the same assertion about Windows, someone can easily compile from their system and attack the target system. Still, I feel the only reason why all these compilers aren't being used for more mischief is because they are much more easier alternatives. Now, is this just me? Am I just an old dinosaur in the age of .Net? Am I the only one that finds the presence of these compilers on ordinary non-developer boxes unsettling?
3 comments:
If an attacker has compromised a system and gained code execution privileges why would they get source onto a machine and compile rather than just execute code?
This is particularly true for Windows that have relatively uniform hardware architecture - something I guess you could never guarantee on an arbitrary UNIX machine.
"If an attacker has compromised a system and gained code execution privileges why would they get source onto a machine and compile rather than just execute code?"
Well, for one, because code execution doesn't mean escalated code execution.
Consider power users under Windows. The blog entry by Mark Russinovich entitled "The Power in Power Users" details why power users are a bad idea, but they are, unfortunately, very much in use today and still exist under Vista.
I can hide the malware as source and do nothing if installed and executed as a regular power user. However, if escalation is gained, I can write out the source, compile and execute.
Even with UAC, you would only get a prompt when running the host program, not when actually executing the malware itself.
That being, you can do all of this in code but your chances of being caught are higher.
Finally, all of this to say that this one vote for dinosaur.
It's sad to say, but the days of careful box configuration, ensuring they only do what they're supposed to do, are long gone.
Most computers these days are multi-purpose and require more and more software and services to fulfill their purpose, each time adding another layer of potential exploitation.
I'd say pick your battles. Production or information sensitive boxens ought to be locked down as much as possible, utilizing all the methods you mentioned... But Desktop machines for Joe Blow do tend to have plenty of 'easier alternatives' for exploitation that I'd say it's easier on the health to just live in blissful ignorance of that, because would you really expect a Windows system to be exploit-free anyways:)?
In a perfect world.....
Post a Comment