Hacker News new | ask | show | jobs
by nimrody 1651 days ago
It's amazing that this library is used by so many large enterprises yet none of them made an effort to thoroughly audit the code (actually, it looks like Alibaba reported the first one. But the point stands that the code was used for so long and by so many.)
6 comments

Code auditing is extremely expensive. I recently did some napkin math and my estimate is that for our relatively small project (a company of ~10) it would cost between 2 and 12 million dollars to have our rust dependencies audited, with Rust making up ~60% of our codebase.

And that's a point in time audit. To maintain that value we'd have to redo the audit periodically.

It's just not gonna happen.

I assume at this point that this library has been audited many, many times by skilled professionals, none of whom thought to abuse the template + JNDI + LDAP chain in this way.

It's just not as simple as "security audit finds all the vulnerabilities, then you fix them." You invest X in the review, you get the results that X/(hourly rate) finds. This is a lot of software with a ton of configurability-- that's a lot of variations to review and test.

Now that someone found the first lump of gold and gave it away, there are thousands of eyes searching for the next one. These recent findings are all abuses of this same chain of functionality, just along different sets of settings. In another month we might have half-a dozen more of varying severity and scope. That _still_ won't prove that the overall library is then safe, but we will probably have a a little more confidence in this particular bit of crazy template formatting flexibility. Maybe not as much as we had had three weeks ago, but more than we do now.

I did this years ago with an open-source and reasonably popular non-Apache library. The results were so horrifying my boss quickly concluded such audits were outside our responsibility and the time I spent on the audit was written off.

It was especially difficult for us because we’d shipped so much code that used the library, and replacing the library was unthinkable.

Don't ask a question if you won't like the answer.
Dealing with the current vulnerabilities is very likely cheaper than auditing each and every dependency with the thoroughness needed to actually catch those vulnerabilities. Also, nobody within the by affected enterprises gets blamed for those external vulnerabilities, nor are the enterprises liable for preventing them, so there is little incentive to prevent them proactively.
Thats the point. Giving back money for the libraries used might not fix anything and can be difficult in many cases. But the most and important way of "giving back" would be testing and review of the libraries used. If especially the large companies using this library had used some of the dev hours for testing and review, the bug should have been found early on.
Each enterprise doesn't only use this common library, it uses a few more hundreds. If the point of pulling libraries is to save tremendous time in not having to write them, I can assure you managers aren't keen in wasting their gains in looking deeply into what's inside. Spotting the flaws, even with careful reviewing is still unlikely to happen, and would benefit the community at wide over their selfish interests.Enterprises use of open source doesn't adhere to the open source étiquette.
Not only are they not interested in spending time auditing code, your typical enterprise lacks the skillset to do so effectively. They couldn't do it if they wanted to, short of contracting it out.