3 ms·

Absolutely! So many compromises against IoT devices or network equipment come from inspecting the open/recycled firmware. There are a lot of interesting defco

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 https://www.youtube.com/watch?v=OnJ18pyMncE

lucideer 5y ago
Heavy citation needed here I think.
- bravetraveler 5y ago
  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.
  - lucideer 5y ago
    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.
dathinab 5y ago
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.
- lucideer 5y ago
  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.
  - netwo233gur 5y ago
    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?).
    - fragmede 5y ago
      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.

lucideer 5y ago

Heavy citation needed here I think.

bravetraveler 5y ago
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.
- lucideer 5y ago
  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.

dathinab 5y ago

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.

lucideer 5y ago
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.
- netwo233gur 5y ago
  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?).
  - fragmede 5y ago
    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.