“through powers granted via the “EAR” (Export Administration Regulation 15 CFR, subchapter C, parts 730-774), along with a sometimes surprisingly broad definition of what qualifies as export-controlled US technology.”
Boom! I told people they might do that back in the crypto discussions. Custom crypto and high-assurance security are still munitions with only a few things re-classified like mass-market, one-size-fits-all software and use of ciphers in browser. This is what they might do to the rest with the leverage if it was ever truly threatening. They’re already doing it to companies over Huawei.
I also speculated they might have done this to get backdoors in products. A combo of offering payment and threats together. We know they do the payments. I don’t know if they do export threats, though.
“some independent security research would have already found and published a paper on this. Given the level of fame and notoriety such a researcher would gain for finding the “smoking gun””
Bunny is being really naive here or maybe doesn’t understand computer espionage. Most subversion must be done in a way that doesn’t look like subversion. The system just has to be remotely exploitable. The best route to that is to intentionally leave in memory safety bugs or a configuration that enables privilege escalation. Hackers find those all the time in all kinds of devices. They say, “Hey, they just made a common mistake.” Maybe it was there on purpose. We won’t know.
“It’s no secret that the US has outsourced most of its electronics supply chain overseas. From the fabrication of silicon chips, to the injection molding of plastic cases, to the assembly of smartphones, it happens overseas, with several essential links going through or influenced by China.”
And this is why what the U.S. government is doing is incredibly stupid. You could substitute other industries in here. It’s a smarter move to minimize one’s dependency on a country before pissing that country off in a way that can prevent them getting what they depend on.
The best route to that is to intentionally leave in memory safety bugs or a configuration that enables privilege escalation.
There are many routes and often it does not makes sense to focus only on one.
Yet, as long as organization are not held in any way responsible for making very vulnerable software, exploits will remain a very good “deniable backdoor”.
“often it does not makes sense to focus only on one”
I mentioned several classes of problems that cause almost all hacks in the field for these kinds of devices. Each class, such as memory unsafety or poor configurations/services, can lead to a multitude of specific exploits.
“as long as organization are not held in any way responsible for making very vulnerable software, exploits will remain a very good “deniable backdoor”.”
If corporations are liable for bugs, then no software will ever be made except from super corps that can afford extremely thorough processes.
Imagine writing a script to search youtube for cat videos, putting it online and somebody used it and somehow through some chain of events, he ended up dying and you got sued for millions?
Liability law in Germany kind of works this way, and as a result nearly everyone has personal liability insurance that costs a few Euro a month and covers up to tens of millions of Euro of damage. Two examples I’ve been given: if you accidentally spill coffee on someone’s laptop at a coffee shop you’re liable to pay for the laptop, and if you jaywalk (therefore breaking the law) causing a car to swerve into a building you’re liable for basically all the damage caused. In both cases (and, I believe, the example you cite), you would be covered by Privathaftpflichtversicherung. The insurers are solvent at such a low cost because the heavy-hitting events are relatively rare.
That gives me an idea along the lines of patent trolls. You sue the companies making insecure crap to fund high-quality, open alternatives. Each time, do write-ups on how little it cost to increase security with fairly-high velocity of features developed. They’ll constantly be reminded they can lose a huge pile of money or spend a fraction of it doing secure process. Some might even do it.
Dont know German laws, though. Can’t assess practicality.
That’s too broad a statement. It would be too broad a legal standard, too. What I advocated in similar discussions is that they be required to achieve a few goals or do a few things that cover the majority of problems. These things would be cost-effective. Examples include memory-safe languages, using secure approach to remote access (not Telnet), property-based testing on what logic they can encode, fuzzing, secure OS, and, if having the money, independent assessment by hackers. How much they’re expected to do goes up with what resources they’re earning off the product.
So, a small player building software to be resistant to at least code injection might use Rust with overflow checking on deployed on OpenBSD with OpenSSH for remote access. Nobody is blowing any budgets making this choice. They’re highly unlikely to be sued for hacks since it’s safer and more secure by default. That’s the kind of thing I’m thinking about. As a side effect, the market would shift piles of resources into creating ecosystems using all that stuff.
Furthermore, in addition to considering requests to merge code from a technical standpoint, one has to also consider the possibility that the requester could be subject to the influence of Huawei, in which case accepting the merge may put you at risk of stiff penalties under the IEEPA (up to $250K for accidental violations; $1M and 20 years imprisonment for willful violations).
“through powers granted via the “EAR” (Export Administration Regulation 15 CFR, subchapter C, parts 730-774), along with a sometimes surprisingly broad definition of what qualifies as export-controlled US technology.”
Boom! I told people they might do that back in the crypto discussions. Custom crypto and high-assurance security are still munitions with only a few things re-classified like mass-market, one-size-fits-all software and use of ciphers in browser. This is what they might do to the rest with the leverage if it was ever truly threatening. They’re already doing it to companies over Huawei.
I also speculated they might have done this to get backdoors in products. A combo of offering payment and threats together. We know they do the payments. I don’t know if they do export threats, though.
“some independent security research would have already found and published a paper on this. Given the level of fame and notoriety such a researcher would gain for finding the “smoking gun””
Bunny is being really naive here or maybe doesn’t understand computer espionage. Most subversion must be done in a way that doesn’t look like subversion. The system just has to be remotely exploitable. The best route to that is to intentionally leave in memory safety bugs or a configuration that enables privilege escalation. Hackers find those all the time in all kinds of devices. They say, “Hey, they just made a common mistake.” Maybe it was there on purpose. We won’t know.
“It’s no secret that the US has outsourced most of its electronics supply chain overseas. From the fabrication of silicon chips, to the injection molding of plastic cases, to the assembly of smartphones, it happens overseas, with several essential links going through or influenced by China.”
And this is why what the U.S. government is doing is incredibly stupid. You could substitute other industries in here. It’s a smarter move to minimize one’s dependency on a country before pissing that country off in a way that can prevent them getting what they depend on.
There are many routes and often it does not makes sense to focus only on one.
Yet, as long as organization are not held in any way responsible for making very vulnerable software, exploits will remain a very good “deniable backdoor”.
“often it does not makes sense to focus only on one”
I mentioned several classes of problems that cause almost all hacks in the field for these kinds of devices. Each class, such as memory unsafety or poor configurations/services, can lead to a multitude of specific exploits.
“as long as organization are not held in any way responsible for making very vulnerable software, exploits will remain a very good “deniable backdoor”.”
You nailed it there. It’s an externality to them.
If corporations are liable for bugs, then no software will ever be made except from super corps that can afford extremely thorough processes.
Imagine writing a script to search youtube for cat videos, putting it online and somebody used it and somehow through some chain of events, he ended up dying and you got sued for millions?
Liability law in Germany kind of works this way, and as a result nearly everyone has personal liability insurance that costs a few Euro a month and covers up to tens of millions of Euro of damage. Two examples I’ve been given: if you accidentally spill coffee on someone’s laptop at a coffee shop you’re liable to pay for the laptop, and if you jaywalk (therefore breaking the law) causing a car to swerve into a building you’re liable for basically all the damage caused. In both cases (and, I believe, the example you cite), you would be covered by Privathaftpflichtversicherung. The insurers are solvent at such a low cost because the heavy-hitting events are relatively rare.
That gives me an idea along the lines of patent trolls. You sue the companies making insecure crap to fund high-quality, open alternatives. Each time, do write-ups on how little it cost to increase security with fairly-high velocity of features developed. They’ll constantly be reminded they can lose a huge pile of money or spend a fraction of it doing secure process. Some might even do it.
Dont know German laws, though. Can’t assess practicality.
Alternately, insurance companies could base premiums off of audits or other evaluations of risk: https://www.dhs.gov/cisa/cybersecurity-insurance.
That’s too broad a statement. It would be too broad a legal standard, too. What I advocated in similar discussions is that they be required to achieve a few goals or do a few things that cover the majority of problems. These things would be cost-effective. Examples include memory-safe languages, using secure approach to remote access (not Telnet), property-based testing on what logic they can encode, fuzzing, secure OS, and, if having the money, independent assessment by hackers. How much they’re expected to do goes up with what resources they’re earning off the product.
So, a small player building software to be resistant to at least code injection might use Rust with overflow checking on deployed on OpenBSD with OpenSSH for remote access. Nobody is blowing any budgets making this choice. They’re highly unlikely to be sued for hacks since it’s safer and more secure by default. That’s the kind of thing I’m thinking about. As a side effect, the market would shift piles of resources into creating ecosystems using all that stuff.
Furthermore, in addition to considering requests to merge code from a technical standpoint, one has to also consider the possibility that the requester could be subject to the influence of Huawei, in which case accepting the merge may put you at risk of stiff penalties under the IEEPA (up to $250K for accidental violations; $1M and 20 years imprisonment for willful violations).
Mmmm sweet sweet freedom :\