Slashdot Mirror
Ask Slashdot: Reviewing 3rd Party Libraries?
Carcass666 writes "It is usually good to use existing libraries, rather than reinventing the wheel, especially with open source. Unfortunately, sometimes we have to work with closed source implementations. Recently, we were diagnosing a .NET assembly and, after getting nowhere with the vendor, ran it through a decompiler. The code was a morass of SQL concatenation, sloppy type conversions, and various things that are generally thought of as insecure.
My question is: What are Slashdot readers' preferred tools for analyzing .NET and Java compiled libraries (not source code) for potential security vulnerabilities? Ideally, I would like to know if a library is a security liability before I code against it. For example, Microsoft used to have something called FxCop, but it hasn't been updated for current versions of the .NET framework."
My question is: What are Slashdot readers' preferred tools for analyzing .NET and Java compiled libraries (not source code) for potential security vulnerabilities? Ideally, I would like to know if a library is a security liability before I code against it. For example, Microsoft used to have something called FxCop, but it hasn't been updated for current versions of the .NET framework."
I don't check libraries for security vulnerabilities. I check websites for information about that, and to see how often the provider is refreshing the library with patches and fixes.
If I don't get the feeling that they take their security seriously, I don't use the library. I'm not about to start testing every library of the OS that I build against, nor the Java stack itself. To do so is asinine unless you're in an extremely high security arena -- you have to start with a certain level of trust, and if you don't trust your vendor, don't use them.
Besides, not one of the binary analysis tools I've ever heard of did a really good job. Even source code analysis can miss bugs. If it were possible to fully automate testing in such a fashion, testers wouldn't have jobs.
I do not fail; I succeed at finding out what does not work.
Committing to a 3rd party library is a lot like adopting a child. It's a long term commitment that's not easily broken, and you can't ever have a thorough understanding of what the relationship will be like ahead of time. I started a long post about the 3 main reasons for going with a 3rd party library, but decided to delete my long-winded rant. I'll just say that for the most part it comes down to saving time (and thus possibly money). You're rolling the dice and hoping at the end of the day (whenever that is - 5 years from now, 10 years from now?) simply utilizing a 3rd party library will have saved you time and money.
I think I have a hard time with commitment (as in platforms, OSs, and 3rd party libraries), and that's probably to do with the number of platforms I've been involved with over the years, and the number that are now dead and gone. If you are the type to embrace and commit (like "I love Microsoft and I love C# and I'm going to jump in with both feet and that will be my universe") then sure, go ahead and use as many 3rd party libraries as you can. If you hope to have any kind of future portability of your code (as in compiling versions for Windows, iOS, OSX, Android, Linux) then you are entirely at the mercy of those 3rd parry libraries and what they will or won't support down the road. I mainly write code for myself (my own products I market), thus I consider the code I write as an investment. That is why I primarily use C++, because it is the only language I can create native applications in for all the platforms I just named (and more), and also why I look for public domain code or libraries with licensing and source code availability so I will know my future using that library is assured (I can build for other platforms, even if that means doing some work porting the code a bit).
I know that's not really answering you question ("How can I know if I can trust a 3rd party library"), and is more an answer to the question "Should I be using 3rd party libraries in the first place?"
Better known as 318230.
Two tools that I use regularly to check Java artifacts: FindBugs: http://findbugs.sourceforge.ne... OWASP Dependency Check: https://www.owasp.org/index.ph...
IIRC FxCop is a source-code analyser.
No it is not.
FxCop is a free static code analysis tool from Microsoft that checks .NET managed code assemblies
http://en.wikipedia.org/wiki/FxCop
FxCop actually works pretty well for what was asked for. Microsoft hasn't failed to update FxCop instead they integrated it more into Visual Studio. You can also write your own rules if you have to keep it updated. I would follow the ASP.NET source code project on codeplex, their build scripts integrate code analysis using nuget and a few other msbuild tricks but i do not think they have it setup to scan another assembly. It can't be hard to configure it too however.
All that said i think everyone else's advice is better.
Limit your use of 3rd party libraries as much as possible for many reasons let alone upgrade paths can be difficult.
Use a tool like nuget to make sure they are updated properly.
Follow the projects closely for changes.
For example, Microsoft used to have something called FxCop, but it hasn't been updated for current versions of the .NET framework
FxCop is still under active development and ships with Visual Studio 2010, 2012, and 2013. They merely changed the name to "Code Analysis"
http://blogs.msdn.com/b/visual...
in my day job I work for Fortify. You can contact the developers of this library and request that they use static analysis product on their software, or request a security review from a 3rd party. We would for sure catch those SQL injections and more. But we would need the original source code. You can probe for things from the binary, but the results don't come back in a way that is very actionable for the developers. As for your predicament: I think you would be better off writing your own library, rather than putting the insecure one to work.
Don't expect .NET decompilers to faithfully reproduce statements as they were in the original code. What you get is functionally equivalent to the original source but it will have been munged by two tools along the way. It isn't necessarily indicative of bad coding practices. Higher level deficiencies like the SQL processing cited will still be obvious and the tools won't impact poor design decisions.
I am becoming gerund, destroyer of verbs.
In situations like this I usually recommend arson.
Good security comes from a lot of people's testing and input. If you look investigate a product, you will only be able to categorize it into two categories: "utterly craptastic" and "probably utterly craptastic". The only way to be assured of good quality is to use libraries that a lot of people use and have had success with. Don't bother looking at the binary, look at the reputation.
What a great feeling it must be to pay extra for the privilege of fixing their bugs for them. Did they at least give you a discount? (Rhetorical question; I know they didn't.)
We paid for the privilege of not being dependent upon then, of controlling our fate. Our barely on time project only lost two days. It was a win-win.
The point being that you paid extra to get the source and *then* not give you anything back for improving their product. I'm hoping they weren't that ungrateful.
We paid for a library that was useful and saved us time. We paid extra to not be dependent. We contributed back our fixes to help other users of the library and to simplify things when we got an update. In those updates, some bugs were fixed by the developer of the library, others were fixed by other customers.
Did you think that one user can only help another user in the FOSS world? One user can help another as long as they have access to source, and such access does not require FOSS.