Library Security

by The Slakker

You don't know me, but you probably know about as much about me as you'll ever know about the people who author libs you graft onto your applications.

Some random dude (supersnarfer9775) popped out some helpful library that spares you several hours' (translated to days of actual if you're spare-timing it) work.  See, I was thinking the very same thing when I found a highly reviewed lib linked directly from the json.org homepage for C/C++.

I tested it using standard data that I'd be tossing to it, I tested it with common erroneous data, then I built my whole app around it.  Also, I assumed that, with dozens of recommends, it had been tested and validated for overflow-type attacks.  Even though the C++ components (OO-stuff) never worked properly, I was O.K. using the out-of-place C-style for now and just writing my own wrapper later or maybe even my own lib from scratch.

After finishing the module that processes the input, I decided to do some buffer-overflow/bounds stress-testing on my app...

When sending in an obscenely oversized numeric and requesting an integer conversion, I expected either an error or a truncated numeric (either the value of MAX_INT or something like that).  I instead received a chunk of binary data from some undisclosed segment of memory.  Pen-testers know, this is code-injection possibility time.

Now, what to do?  (Honestly, I had thought of putting this segment into a choose your own adventure style.)

My thoughts in order:

1.)  Write a pre-parsing limit checker (two day project delay).

I know, bad idea.  It's for a Software as a Service (SaaS) project that has to be secure.  How do I know where all of the problems are?

2.)  Find another similarly-licensed lib (five to ten day project delay).

O.K., sounds very reasonable.

Honestly, it's a ton of work, though, and most of those other libs have open issues with components I needed.

It's as likely I'd have this problem with them as well.

Not to mention I'd have to work my entire data-handling mechanism around yet another stranger's methodology that I'd soon be replacing with my own, anyway.

3.)  Just roll up the sleeves and do the work (three to four week project delay).

Needless to say, I went with Option 3 (so the Choose-Your-Own style would have been a boring series of "FAIL - Turn back").

This, however, should not have been my experience.  This library is mature.  It has been around for a loooooooong time.  The fact that it has this issue is a very telling situation regarding the state of information system security.  Several people had recommended it.  Only one person solidly argued against it and his argument was idiotic from the standpoint of someone looking to treat it as a black-box (he argued that the coding standards reflected in the source were weak and that the lack of commenting to assist in understanding the three-letter function names was annoying, etc.).  What kind of individuals are we trusting here with these free libs that we utilize in our applications every day?  This particular kind of lib is on the front lines...

That said, what can be learned from this experience?

Let me first say that I'm a huge proponent of modularizing code and moving all reasonable segments into libraries for easy reuse and clear grouping.  I'm also a big advocate of library development for profit (either through sponsorship or charging a small royalty per production sale/client - not for development licenses).

Why?

Simple.  If you're making enough money, you'll keep working on it and stay abreast of issues.  Something truly stupid seems to happen to all free libs that aren't backed by large corporate sponsors or that aren't part of a larger, high-momentum project: they stagnate, we find vulnerabilities, and - no matter how promising they were - they die.

I'm not trying to soapbox here, people, but at some point you have to make a living, and if it comes down to spending time with my kids or working on some lib that is a hobby and doesn't pay my bills... well...  I'm picking my kids.  One day we all grow up, priorities change, etc.  However, if we find a way to make a decent enough living from our work, well, we stand a chance at continuing it.

My advice for those looking to develop libs or those who want to help improve the software situation:

1.)  Read a book on secure-coding in C/C++ or whatever your language is.

Trust me, no matter how "safe" it is, there are either configuration options or coding practices that help avoid issues.

At the very least, you may learn alternatives to certain constructs that will massively improve performance, like getting the length of an array once in PHP before starting a loop to iterate through.

2.)  Get it peer-reviewed, preferably by someone who knows how to check for the injection-kind of issue (since it's a less obvious back door that people exploit regularly and it's often undetected).

3.)  Don't pop out version-after-version of insecure code; have it re-tested after each patch, no matter how minor the adjustment seemed.  Believe it or not, most patches open up more options than they close for penetration-testers due to the tunnel-vision of "I have to fix problem X" combined with "Angry people are emailing me!"

4.)  If you do pound out an insecure version, patch it, own the mistake (mailing list and/or website news advisory), and accept your penance (support the developers you screwed).

To the hacker community:

We're an inventive lot.  Let's work together to discover issues with libs like these, especially fundamental data and comm libs that will be right on the frontlines, and warn developers to steer clear of the garbage.  Who knows, you might actually spot an opportunity to pop out the first secure library that fits a niche and make a little bread to boost your rig.

In the end, the only reason people fear us and flip out when we make announcements is that they don't see us participating in the "food chain" of the industry.  That's simply not true.  We are all through it.  We just need to start taking an active role in pointing out the massive flaws present in these systems and showing how using us to plug the leaks is a superior methodology to shunning us and ignoring our notifications.

After all, ancient Japanese Lords would use Ninjas to defend their castles and territories against other Ninjas for a reason: You have to think like what you hunt.  I'm not suggesting we don suits and stop hacking, I'm suggesting we show how amazing our skills are and how constructive we can be.