
Ask Slashdot: Reviewing 3rd Party Libraries? 88
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."
Open source (Score:1)
Easy: use open source libraries.
Source code can come with proprietary libs ... (Score:2)
Easy: use open source libraries.
Yes, having the source code to a library is very important. However open source is not the only way to go. Source code can come with proprietary libraries. Some commercial vendors of proprietary libraries offer binary-only licenses and more expensive source code licenses. I've had more than one reluctant manager come to realize that the extra expense of the source license was absolutely worth it. We fixed some bugs that affected our project, gave the fixes back to the vendor and found our fixes incorporated
Re: (Score:2)
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.)
Re: (Score:3)
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.
One user helping another also happen in non-FOSS (Score:3)
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.
Re: (Score:2)
In this particular case, the library is a component of a deployed system (put into place before I got here) for inventory management. The library is the "documented" way to be able for our website to be able to query the system and to be able to perform operations on the inventory (take some out of stock, put some back in, etc.). I could deal with the database directly, but then I don't have any guarantee that I am implementing the same business logic as the library. This particular vendor is very touchy
Re: (Score:2)
Easy: use open source libraries.
Yep, like GnuTLS, or Apple's SSL implementation. You know there won't be any bugs in those, or if there are they'll be very quickly fixed and not sit there unnoticed for years.
Re: (Score:2)
Easy: use open source libraries.
Yep, like GnuTLS, or Apple's SSL implementation. You know there won't be any bugs in those, or if there are they'll be very quickly fixed and not sit there unnoticed for years.
I remember back in 2008, when the Debian OpenSSL package was found to have a gaping hole in it. I was fascinated at the fact that it had been able to lie their, dormant, until it was discovered and immediately fixed. By rights, the damage should have been widespread.
Back then, I wrote [imagicity.com]:
My hypothesis – sorry, my speculation is this: People at every stage of the production process and everywhere else in the system trusted that the others were doing their job competently. This includes crackers and others with a vested interest in compromising the code.
So, perversely, yeah: The fact that the GnuTLS hole remained unnoticed for yonks is -weirdly- an argument for using open source libraries. Notwithstanding the fact that the vulnerability remained unpatched for years, it appea
Do you want your code to work all the time (Score:2)
If yes:
Only use language defined standard libraries and build everything else you need yourself, and even then trust but verify. The third party libraries are always going to be cobbled together.
If no:
Fuck it.
Re: (Score:2)
And make sure you don't do a even worse job.
Re: (Score:2)
No, they're all shit. The open source ones, if they're really popular and get a lot of eyeballs, are okay.
Re: (Score:1)
Agreed.
Libraries always have bugs - just like any other code - and pretty much always have crap documentation - just like any other code -. The more obscure, the worst. Open or closed source is irrelevant, but open source ones tend to be more popular, ergo...
They also frequently enough do 95% of what you want, except for that key small bit the authors didn't think about that you only discover for a new feature, 6 months and 2 releases in when your pretty much wed to it.
At least with open source you can:
a) f
Re: (Score:2)
Cool I'll just get started on reimplementing OpenSSL.
Short answer: I don't (Score:5, Insightful)
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.
Re: (Score:2)
I'm not about to start testing every library of the OS that I build against, nor the Java stack itself.
Which is sane, but if you use an open source OS and an open source Java stack, there are other people doing that kind of testing, and even more importantly, social pressure for the developers, because they know other people will be looking.
If you're using a secret-source library, then you're completely at the developer's mercy (though your OS can detect certain atrocious behaviors). Like a sibling post
Re: (Score:1)
Which is sane, but if you use an open source OS and an open source Java stack, there are other people doing that kind of testing, and even more importantly, social pressure for the developers, because they know other people will be looking.
That's funny since there was plenty of "social pressure" on GnuTLS about its crappy code and yet it had unfixed security flaws for most of a decade.
Re: (Score:2)
That's funny since there was plenty of "social pressure" on GnuTLS about its crappy code and yet it had unfixed security flaws for most of a decade.
You'll notice that FileZilla is the only major app [archlinux.org] that uses it for online work, and that's mainly used by Windows people.
The 'society' knew to use openssl.
Re: (Score:2)
That is an illusion. I have seen Open source code which looks like shit if you take 10 Minutes to look into it. I have seen worse close-source, though, but i have also seen great closed source code.
If you really need to have a look at a close source lib, you can sign a license agreement with the compnay in question.
Re: (Score:2)
. I have seen Open source code which looks like shit if you take 10 Minutes to look into it.
Of course you have - anybody can open source anything.
Have you seen major, mature, popular projects with code that looks like shit?
Re: (Score:2)
Major and popular: yes, one or two. And dont expect me to go into the details. Look for yourself.
Typical sicknesses to look out in open source code:
-bad glue code
-missing or ill-defined tests
-lack of documentation
-code which the current maintainer imagined to start a ne coding style (and misestimated the work associated with this)
Still, i have to admit, the worst open source i have seen comes from commercial projects open sourced at some point.
Re: (Score:2)
About the only way to deal with third party libraries is through the terms of the contract. If you agree to license it, you're going to hold them responsible for security violations. Perhaps you stipulate they must run their code through a designated scanner like Fortify or Klocwork and they must agree to fix all critical or severe errors, or that they undergo an annual independent code review.
If all that seems like it's too heavy handed for a simple library, just wait till you get hacked. That's a lot m
Do not use FXcop as any promise of quality. (Score:2)
Re: (Score:2)
I don't check (I prefer word "review" or "audit" here) the libraries for security vulnerabilities before I start using them. However, I only accept libraries than come with the source and I do cursory review of the code with a question in mind:
Only if the code looks sane enough that I can answer "yes" I even start using the library. And the security is only a small part of the picture here! If the library doe
Reflector is the way to go (Score:2)
On the other hand, Red Gate's Reflector decompiles the code into C#, VB.NET, F#, IL, or MC++. You can then look for malicious code. I mainly look for code accessing classes in the System.IO namespace, System.Web, System.Net, or similar namespaces, because these are the ones that are likely to either mess with e
Re: (Score:2)
Or if you don't want to pay for Reflector, you can use ILSpy [ilspy.net] (a free and open source .NET Decompiler), dotPeek [jetbrains.com] (free, from the markers of Resharper), or JustDecompile [telerik.com] (free, from Telerik).
open source only (Score:2)
IIRC FxCop is a source-code analyser.
There are others, Fortify 360 is one I used at a security-conscious company. But in all cases, they require the source code
Though, to be fair, if you're using a 3rd party closed-source library, then you're at the provider's mercy and should go for other avenues of protection - if you can't see security updates coming regularly, then after the fact protection works: you sue them if it fails. Generally, you don't need to know the source for a closed-source library, its a b
Re: (Score:2, Informative)
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
OWASP has tools (Score:1)
Try OWASP's DependencyCheck tool. https://www.owasp.org/index.php/OWASP_Dependency_Check .NET vulns as well. Good quality project and developers. The tool essentially tells you if there are publicly known vulns (CVE's).
It was originally built for Java, but they are starting to move towards
Apart from that, various static analysis tools work on binaries, both commercial and open source. For Java open source, try PMD or FindBugs. For .NET, FxCop was what I would have recommended.
Write your own code and use FOSS (Score:2)
Re: (Score:2)
Reverse engineering is legal in the US. If you only gain knowledge of internal workings and don't reproduce copyrighted or patented code then there are no damages a vendor can pin on you even if it violates a restrictive license. The worse they can do is revoke the license and force your management to select a better vendor.
This sucks (Score:2, Insightful)
Re: (Score:2)
Is it still a thing? I get Slashdot classic right now, and I thought they had given up on this thing. See how it looks for me - http://imgur.com/k8JEJsU [imgur.com]
Adoption (Score:5, Interesting)
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?"
Re: (Score:1)
I'm pretty sure you can create native applications in C# for all the platforms you named.
Java tools (Score:2)
Defensive in depth (Score:1)
Re: (Score:1)
1. Make the code compile (what!!!, I'm not allowed to commit uncompilable code to my team mates???).
2. Make the code compile, without warnings (when it does, enable 'treat warnings as errors').
3. Make the code compile, without any analysis warnings.
4. Make all unit tests pass.
5. Make all system tests pass (in the test/staging environment).
Y
No source? (Score:1)
Sorry for the radical answer, but if you don't have the source code you should assume it's unsafe and backdoored.
not a bot (Score:2)
i'm an idiot...not a bot...just an idiot
gotta be an all-time "did not read past the headline" situation for me...TFA is about...um software libraries
gah...sorry
Re: (Score:1)
"the left" you decry is just normal people from outside the ignorant right-wing bubble.
FYI: FxCop (Score:5, Informative)
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... [msdn.com]
Fortify SCA (Score:2)
Sloppy type conversions (Score:3)
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.
Re: (Score:1)
This should be modded higher. Judging the code quality based on the disassembled code is almost impossible.
The compiler can make optimizations and reorder code based on what it knows is possible / impossible with the code paths. This can end up looking like very poorly written code even if what was originally written was very well structured and conforming to best practices.
Even String concatenation for SQL calls is not necessarily horrible depending on the types and / or validation performed. Assembling
Re: (Score:2)
Oh, praytell, what kind of mainstream porn would you find acceptable for me to wank to.
That's an easy one (Score:3)
I don't have a favorite (Score:2)
And haven't found any that are terribly impressive in their abilities. They'll catch certain kinds of problems, but tend to lose their way pretty fast in more complicated code. Anyway, this list might help start you out in the right direction:
http://en.wikipedia.org/wiki/L... [wikipedia.org]
Many Eyes (Score:4, Insightful)
Re: (Score:2)
That's utterly crap advice. Since a lot of softwares in popular, active use have critical vulnerabilities.
The example quoted just above (http://ask.slashdot.org/comments.pl?sid=4862577&cid=46414687) in which nobody got the sarcasm ... says:
He was referring to https://www.gitorious.org/gnut... [gitorious.org] and https://www.imperialviolet.org... [imperialviolet.org], not to mention http://bsd.slashdot.org/story/... [slashdot.org]
"Slashdot ... tools for analyzing .NET and Java" (Score:1)
"Slashdot ... tools for analyzing .NET and Java"
I am partial to "rm"; I have a couple of friends who prefer "unlink", and one friend who prefers "cp /dev/null ".
Seriously, why do you think *anyone* other than "security consultants" analyzes binary libraries? Why do you think FXCop hasn't been updated?
ILSpy (Score:2)
This is not a security analyzer, but ILSpy [ilspy.net] is the .NET decompiler that I currently use. Red Gate .NET Reflector went commercial only, so this is what's left.
Re: (Score:2)
rm - just rm (Score:2)
.Nyet ! (Score:1)
Re: (Score:1)
Re: (Score:1)
And? (Score:1)
Okay, but what were the unexpected things you found?
code analysis (Score:1)
Hp Fortify (Score:1)
Guidelines not Software Tools (Score:1)
You mention "Tools", did you mean "Software Tools". And, you have to use a decompiler.
I think, "Reviewing", in this case, means more like guidelines & I.T. (rules) policies.
Things, you may want to consider:
* Does a library provides source code ? (No Source Code, preferably, avoided) If you have to pay a extra, for the source code, then choose no library, or pay for the source code, but, dont buy propertary libraries without source code or support.
* Does a library is for a particular programming language