Hacker News Reader

Comment by bravetraveler | Hacker News Reader

Absolutely!

So many compromises against IoT devices or network equipment come from inspecting the open/recycled firmware.

There are a lot of interesting defcon videos about using this method

edit: To clarify, this isn't to imply that I think closed source would necessarily be better.

I think this quote puts it well. An all-too-common story about security in open source... of four people: Everybody, Somebody, Anybody, and Nobody:

"Anybody could have done it, but Nobody did it. Somebody got angry about that, because it was Everybody's job. Everybody thought Anybody could do it but Nobody realized that Everybody wouldn't do it.

It ended up that Everybody blamed Somebody when Nobody did what Anybody could have done."

Source: https://www.youtube.com/watch?v=OnJ18pyMncE

View on HN

Tbh. I doubt that it makes a huge difference.

Some of the best/easiest ways for someone with experience to find vulnerabilities is to throw automatic analysis tools at it. Many of which do work on binaries/disassembly, too.

Don't forget that in many cases it's not too hard to disassemble binaries.

Sure having the source can make it easier, but then things being open source also means that non evil actors might look at you code and help you find/fix problems before they become big. Which I believe somewhat balances it out. (for larger/widely used projects).

Like imagine log4j becoming known because of multiple supper wide spread attacks happening all over the internet, instead of getting known and then fixed and then mass attacks happened because updates take so long. And the log4j vulnerability is totally discoverable without source code. Idk. who found it but I wouldn't be surprised if someone ran into a non-security bug triggered by it and was, hey, wait a moment. Even if it didn't happen like that, it totally could have(1). Closed source would not have helped at all. At best it would delayed it and then made the effects worse due to coordinated wide spread attacks before there is a fix/mitigations.

The log4j incident is an excellent example. A fix to a closed-source vuln of a similar nature would've taken months, compared to ~5 days (if we include the 2nd CVE fixed in 2.16) for an open community response to an open source issue.

I don't know how you can say this... a closed source vuln of this severity would be patched almost immediately. See: any vuln of this severity on iOS or Windows.

On the contrary, log4j incident is an excellent example of how relying on open source for security completely failed. This vuln existed for years, all while being open to security researchers to find it. They didn't. Instead, there is evidence that black hats found the vuln first (perhaps because log4j is open source?).

There's no clear winner between open and closed source, but that's just wrong. Vendors have and will continue to bury (under threat of violation of the CFAA or civil lawsuit) vulnerabilities to prevent hackers from disclosing said vulnerability, rather than fix them. That's also why Google's Project Zero gives a hard 90-day deadline to vendors for patching found vulnerabilities, and they got a lot of flack early on for disclosure.

I literally have not heard a more naive statement on this site, ever. If you work in IT, please educate yourself on this. I'm serious.

I'm a senior security engineer at a FAANG. You're completely oblivious to the state of security today you think anything in my comment was naive.

Please, let's continue this back-and-forth of condescension. It's really productive. /s

Apologies for the tone, but the content of my point 100% stands. For what its worth, I have dear friends at multiple FAANGS who I'd die for -- who nonetheless strongly appear to have a wildly overinflated sense of their own cybersec, in a big picture "missing the Black Swans" sort of way -- if the past is any indicator.

Maybe it's not, maybe you guys have drastically improved things. What makes me strongly doubt it is that we still haven't seen substantial liability or other consequences for bad or negligent actors in this space.

> maybe you guys have drastically improved things.

FAANG security is just like everywhere else: mixed. There are mixed levels of knowledge & experience, and mixed views: i.e. even though there's a lot of consensus on high-level tenets and frameworks, like e.g. Google's Beyondcorp stuff (along with some certain security 101 stuff that's been discussed for the past 138 years), you'll always get engineers who don't like X or Y. Just like anywhere else.

Nothing is a continuum.

I'm not sure if this is a reply to my original poor phrasing where I mistakenly said 'all' instead of 'so many'. I'm sure even that may be a bit generous. We're in niches of niches, here.

It seems the places where the manual digging occurs most are with devices where nobody has even thought or bothered to use such tools.

The vulns the people find are often incredibly laughable; unauthenticated actions leading to a clever path to higher privileges.

Heavy citation needed here I think.

I didn't write this with anything specific in mind; it's based on a binge of Defcon videos from at least a year ago - consider that my citation.

Honestly, anyone that invests the slightest amount of effort in researching how vulnerabilities are found could arrive here. I'm surprised there's skepticism, quite honestly.

It often comes down to the would-be attacker downloading a published update, looking around the PHP or whatever within, and finding unprotected or bugged APIs to leverage -- often to write their own modified version of that same update.

Well if I re-read your comment, you technically don't say anything too controversial: "so many" isn't really countable.

But the implication is that compromises were found because those firmwares were open and/or that closed firmwares suffer fewer similar compromises. Which is what I would question.

Reply on news.ycombinator.com