Comment by zer00eyz | Hacker News Reader

Comment by zer00eyz | Hacker News Reader

Two malicious Python libraries caught stealing SSH and GPG keys: https://news.ycombinator.com/item?id=21701488

Raise your hand if you are executing code in your project that was written OUTSIDE your organization, and has never been reviewed by people within your organization.

This is the ham sandwich problem.

If a stranger walked up to you on the street and handed you a ham sandwich would you eat it? I would venture to guess that most of you would NOT. However many of us are all too happy to grab some random chunk of code off the internet and shove it into production without a second thought.

Personal and social information of 1.2B people discovered in data leak https://news.ycombinator.com/item?id=21606415

Is this another ham sandwich from a stranger that has been eaten? How often is the "bug" implicit trust and poor design or default behavior?

What about Specter? A hardware level exploit was bound to come up again, we have had hardware bugs before (1994 pentium math bug) but exploitable ones are "fairly rare".

------------

The old mantra "security through obscurity" is true, but it has some serious validity issues when there aren't enough eyeballs on the software we are already running, and were generating more at a rate where people can NOT keep up! (This doesn't address the fact that we are now building opaque boxes with ML that NO ONE understands accurately).

My favourite comparison for all the 3rd party library use is, if you walked in to the CEO of your company and said

"we want to hire some people with no background checks, no interviews and no idea where they live to write code for our critical line of business application. We're then going to put that code into production without reviewing it, and regularly update it without reviewing the updates. Oh also we won't have any form of enforcable contract as come-back if something goes wrong."

You'd, at best, be laughed out of the room.

Yet that's exactly what pretty much every company does with 3rd party libs.

On the contrary, you'd be asked what the cost benefit analysis was vs doing it in house, then told to continue.

CEOs outsource critical things without meaningful oversight all the time.

The point I was flagging up was the dissonance of corporate hiring policies relative to their use of third party code.

For hiring, no chance you'd get that policy past corporate HR in any large company. Try hiring a developer sight unseen to work remotely with no contract in any large organization and see how well that goes.

Yet companies effectively do just that with 3rd party library use. the reason the CEO doesn't do anything isn't likely to be because they've made an informed risk decision on the topic, it's because no-one is telling them the risks :)

I work for a 10,000+ person public company that just outsourced critical business functions via a 5 year contract that doesn't have any meaningfully enforceable description of the work to be done.

If you're trying to talk about hiring for full time employment as opposed to contract work... what happens there is as long as people are able to get through whatever idiosyncratic hazing process was involved in hiring, they're going to be at the company for at least a year. It's perceived as hard / risky to fire people, even if they can't program their way out of a wet paper bag.

This stuff happens all the time, it's not that different from evaluation and use of third party code. "This project has 500 stars on github, it must be good." "This guy used to work for Google, he must be good." Now you're stuck.

In the first case you still have a contract, and therefore contact law in your country applies. Blatent breach like "they wrote code that stole all our SSH private keys and then they deployed cryptocoin mining software to our systems" would be covered, regardless of how bad the contract is.

Same with hiring, the person may or may not be able to code, but active malice would likely result in firing, and the code they write should be subject to review before being put into production.

Of course you can argue "hey where I work hiring is trash, we write bad contracts and have no internal standards, so this 3rd party stuff isn't much worse" but I'd suggest that's not an argument most companies would make publicly about their processes.

Whether they'd make the argument publicly or not, it's still true that it is the reality, and the company I currently work for is better than a lot I've seen.

Point taken about active malice... but I've also seen companies with mostly in-house code cover up instances of rootkits on production servers and malfeasance related to credit cards.

I'd rather companies use third party open source crypto, for instance, even if it sometimes gets compromised, because it's a lot more likely to come to light.

It comes down to incentives. I maintain that the problems for a system occur in proportion to how far the user is from the customer.

In the sandwich case, the user is the customer. You wouldn't eat the sandwich, because it might make you sick.

In the software library case, the developer sees the benefits of using a library, but rarely sees any penalty if it goes bad. They'll earn the same paycheck, and probably even work the same hours. They might not even be the same team that has to deal with security issues in production. They get the benefit of saving time, and accept none of the responsibility.

This may be a field where future machine learning algorithms might shine: Code vetting. It would be hard but much more interesting than classifying cat videos. The amount of code involved in software projects will not decrease and if we don't vet it ourselves, we need something that does it for us. Even if we wanted to vet code ourselves, we might stumble over complexity. Will my software fail in interesting ways if I use library module X this way?

Reply on news.ycombinator.com