If you loaded an opensource firmware on the netgear like he said, you would not have been vulnerable to that bug because you would not have been running Netgear's firmware.
(Recently got a chance to configure some of NetGear's prosumer/enterprise gear and it was mostly sane... allowed you to turn off all the crap and put all the mgmt on an out of band interface and/or pick and choose which services bound to which SVI. They claim they are starting to take this security more seriously, and at least on the enterprise side it looks like they might be.)
Ethernet is always going to be the safest way to connect.
Well... I can think of a few others that don't have quite the associated broadcast domain and packet forgery issues that require a enterprise level switch (or if you're me, packaging some other guy's dhcp snooping daemon for OpenWRT) to counter... but none that you'll find on the shelf at Fry's.
a good minimal install of Linux is a good secure option
It is, whether a normal install or a WRT-based. The big problem is keeping it minimal. Distributions are founded all the time with an aim to be minimal and the same thing happens... a few years later their coming "out of the box" so to speak with crap like avahi-daemon running and dozens of open ports for different flavors of media servers and whatnot.
weekly updates furthermore are a must have and the lack of it is a major weakness of routers
Anything that needs weekly attention is running too much features/code. On a router you want to keep your attack surface area so low that you're really only exposing a few very simple and well worn services. If you are dealing with more than one effective exploit every year or two, you're running something you shouldn't be running on a router. In addition, it is not uncommon for "updates" to secretly enable new features without explaining their security implications or introduce bugs that didn't used to exist (e.g. the whole Cisco Smart Install debacle.) If you're doing it right, you'll read the bug reports and 95% of them will not affect you because you disabled that ridiculous feature, 4% will be "well, glad I haven't updated in two years and my software is too old to have that", and if you are lucky the 1% of things that might actually get you can be worked around with just a config adjustment. Upgrades are for the unlucky days, actual need for new features, or when you just can't psychologically live with yourself for running a 7 year old software load.
As to TFA, since you have hacking chops, the biggest thing you can do improve your security is the thing nobody does because it is inconvenient: isolate your management interfaces on a separate hardware port and plug in by wire when you need to make any administrative changes. The second biggest thing you can do is start with a router that blocks everything and then painstakingly figure out precisely what packets need to be allowed in, out, and across that router, and permit only exactly those packets (hint: ICMP is actually kinda important.)
The problem I have with this solution (which is basically the Nissan one) is that you are relying on the spring/clutch to not wedge up and just sit there (or in the case of a meshing system rather than a clutch, fail to interlock.) This has to work flawlessly under conditions that may include abrupt jolts due to collisions or terrain. An assembly that stays assembled is less likely to have those problems, and already has decades of in-the-field testing behind it.
Well, TBH, if it were plausible on an engineering/cost level, I might be just fine with a rheostat/variable-capacitor-based backup braking system on PM motors, as long as there still was a pad-based cable controlled e-brake for the last 5mph. (Try this experiment, short a stepper motor, then notice how hard it is to turn.) Of course, dumping all the waste heat without a disk or drum is a bit of a challenge in that case, even if you could get it to work at the currents/voltages involved in stopping a multi-ton car from highway speeds.
I can trust very simple analogue electronics for emergencies, but trusting an active control system to work in a pinch is something I'm simply not inclined to do.
All the by-wire stuff spooks me, I'll never buy a car that doesn't have permanent direct mechanical coupling backups for steering and brakes... Nissan's dont-worry-the-coupling-reengages-if-the-power-fails doesn't cut it, even if it can get passed the regulations.
Some talented screenwriter could probably make a good movie screenplay out of a battle-royale between Siri and Alexa and Okaygoogle all trying to sabotage each other, meanwhile ruining the life of their owner. (And then get the companies to buy the rights so it'll never get shot)
Meh. I did bother to google at one point and read a nice paper on a formal language for a formal pre-silicon design security validation language. But I closed the tab, and am bored with it now. You do know that subcontracting designs is a decades long practice and hardware trojans have been around for so long that the industry is on top of this problem, right? If you're concerned about "analogue security", lower your damn clock speeds so you aren't running all your gates right up to the edge of their specs. And feel free to google yourself. It's not hard information to find.
Well, maybe he was right. In this case, the engineers were the users who lacked the discipline to test the veracity of the documentation for the closed system for which they were writing their... pfeh... OS code. Real men design microcode dispatchers.
...not to mention you won't be able to approach any device without a ski mask on for fear of accidentally logging into something you don't want to log into.
Actually, there is a difference on the back end and usernames are used for good reasons. The username indexes more than your password, and is usually safe to record to logs and expose to a larger code surface in the AAA infrastructure. (With logs, best practice is to only record usernames from existing accounts in case a password accidentally gets typed in the username field... but of course make sure there's no delay introduced by doing so that would allow testing which usernames are valid.)
Also in challenge based password crypto systems, with no invariant part of the secret, you'd have to hash your entire database of passwords with each nonce to have something to compare with the user's response on every auth, and that's gigantically wasteful.
Now the same thing usernames are used for can be done with PKI DNs, of course. The problem with tokens and keystores is they gather a lot of authorization privileges in one place protected usually by a single... you guessed it... password... which is usually cached to keep the store open (just like passwords if you let your users do that.) Which means the store remains available for any software compromising the client machine much longer than necessary.
Also keystores and tokens are not necessarily well designed... they may leak the public contents of a cert to anyone who can figure out what CA/attributes to challenge with rather than asymmetrically validating the server cert first. That won't grant access, but can be used to track users without their consent.
I personally hate the drive for "passwordless" systems since wetware has some pretty good security properties for those that are capable of using it and I don't think depriving those people of that tool is productive. However, if we are going to use tokens, it would be best to insist the token vendor use auditable OSS hardware/firmware like Nitrokey rather than Yubikey.
Maaaaybe if the Obama admin had actually made it a law instead of reinterpreting existing laws it would have been better?
Maybe if the Republicans who controlled congress hadn't started with "make Obama a 1-term president" as their primary stated goal and pretty much refused anything he put forward whether or not they or their constituents agreed with it or it was good for the country.
Unfortunately the New York Cohen case is still a federal case, just in a different federal district. Perhaps that makes it easier for the state to file charges, I dunno.
That's pretty funny... I stopped listening and didn't renew my payed subscription for the exact opposite reason... they were spending all their time developing apps for everything under the sun, and no time improving their supposed core product, which had stopped finding much new-to-me music I liked no matter how much feedback I put in or how many times I started fresh.
YOU are the Developer. It is YOUR obligation to ensure you don't link to bogus, questionable or potentially malicious libraries.
Any library can become bogus and malicious at any given time. One compromised laptop and a keystroke logger to get the DSA key+password is all it takes. I don't think many developers would sign up for a system of "if you write code, you have to stick around and watch that code and all its dependencies vigilantly" because you'd have to stop writing code at age 25 and spend the rest of your life on the full-time job of monitoring what you wrote. The point of volunteer OSS is you are supposed to be able to contribute what you are willing to, when you want to.
Libraries are a double-edged sword security-wise... bugs and compromises in them affect everything, but on the bright side, you only have to fix them in one place, not hunt variants of them down in the thousands. (Not to say that there are not tons of completely redundant libraries due to NIH, megalomania, or just not being aware of other solutions.)
When you see something like TFA happen you need only ask: what work was too menial for anyone to do on a volunteer bases that this was not caught and then you know what the OSS community needs to find someone to pay someone to do.
Slashdot Mirror
If you loaded an opensource firmware on the netgear like he said, you would not have been vulnerable to that bug because you would not have been running Netgear's firmware.
(Recently got a chance to configure some of NetGear's prosumer/enterprise gear and it was mostly sane... allowed you to turn off all the crap and put all the mgmt on an out of band interface and/or pick and choose which services bound to which SVI. They claim they are starting to take this security more seriously, and at least on the enterprise side it looks like they might be.)
Ethernet is always going to be the safest way to connect.
Well... I can think of a few others that don't have quite the associated broadcast domain and packet forgery issues that require a enterprise level switch (or if you're me, packaging some other guy's dhcp snooping daemon for OpenWRT) to counter... but none that you'll find on the shelf at Fry's.
a good minimal install of Linux is a good secure option
It is, whether a normal install or a WRT-based. The big problem is keeping it minimal. Distributions are founded all the time with an aim to be minimal and the same thing happens... a few years later their coming "out of the box" so to speak with crap like avahi-daemon running and dozens of open ports for different flavors of media servers and whatnot.
weekly updates furthermore are a must have and the lack of it is a major weakness of routers
Anything that needs weekly attention is running too much features/code. On a router you want to keep your attack surface area so low that you're really only exposing a few very simple and well worn services. If you are dealing with more than one effective exploit every year or two, you're running something you shouldn't be running on a router. In addition, it is not uncommon for "updates" to secretly enable new features without explaining their security implications or introduce bugs that didn't used to exist (e.g. the whole Cisco Smart Install debacle.) If you're doing it right, you'll read the bug reports and 95% of them will not affect you because you disabled that ridiculous feature, 4% will be "well, glad I haven't updated in two years and my software is too old to have that", and if you are lucky the 1% of things that might actually get you can be worked around with just a config adjustment. Upgrades are for the unlucky days, actual need for new features, or when you just can't psychologically live with yourself for running a 7 year old software load.
As to TFA, since you have hacking chops, the biggest thing you can do improve your security is the thing nobody does because it is inconvenient: isolate your management interfaces on a separate hardware port and plug in by wire when you need to make any administrative changes. The second biggest thing you can do is start with a router that blocks everything and then painstakingly figure out precisely what packets need to be allowed in, out, and across that router, and permit only exactly those packets (hint: ICMP is actually kinda important.)
Yeah! ...Robocalls my ass. That was just his super speed. And a case of JD.
The problem I have with this solution (which is basically the Nissan one) is that you are relying on the spring/clutch to not wedge up and just sit there (or in the case of a meshing system rather than a clutch, fail to interlock.) This has to work flawlessly under conditions that may include abrupt jolts due to collisions or terrain. An assembly that stays assembled is less likely to have those problems, and already has decades of in-the-field testing behind it.
Well, TBH, if it were plausible on an engineering/cost level, I might be just fine with a rheostat/variable-capacitor-based backup braking system on PM motors, as long as there still was a pad-based cable controlled e-brake for the last 5mph. (Try this experiment, short a stepper motor, then notice how hard it is to turn.) Of course, dumping all the waste heat without a disk or drum is a bit of a challenge in that case, even if you could get it to work at the currents/voltages involved in stopping a multi-ton car from highway speeds.
I can trust very simple analogue electronics for emergencies, but trusting an active control system to work in a pinch is something I'm simply not inclined to do.
Well, for a rather tragically definition of funny. Actually a rather Russian definition of funny, come to think of it.
It's required by federal safety standards
...for as long as those last.
All the by-wire stuff spooks me, I'll never buy a car that doesn't have permanent direct mechanical coupling backups for steering and brakes... Nissan's dont-worry-the-coupling-reengages-if-the-power-fails doesn't cut it, even if it can get passed the regulations.
Before the Simpsons?
Some talented screenwriter could probably make a good movie screenplay out of a battle-royale between Siri and Alexa and Okaygoogle all trying to sabotage each other, meanwhile ruining the life of their owner. (And then get the companies to buy the rights so it'll never get shot)
Meh. I did bother to google at one point and read a nice paper on a formal language for a formal pre-silicon design security validation language. But I closed the tab, and am bored with it now. You do know that subcontracting designs is a decades long practice and hardware trojans have been around for so long that the industry is on top of this problem, right? If you're concerned about "analogue security", lower your damn clock speeds so you aren't running all your gates right up to the edge of their specs. And feel free to google yourself. It's not hard information to find.
Ahh, if only mod points went higher than 5.
(snark)
Well, maybe he was right. In this case, the engineers were the users who lacked the discipline to test the veracity of the documentation for the closed system for which they were writing their... pfeh... OS code. Real men design microcode dispatchers.
(/snark)
Actually, there is a difference on the back end and usernames are used for good reasons. The username indexes more than your password, and is usually safe to record to logs and expose to a larger code surface in the AAA infrastructure. (With logs, best practice is to only record usernames from existing accounts in case a password accidentally gets typed in the username field... but of course make sure there's no delay introduced by doing so that would allow testing which usernames are valid.)
Also in challenge based password crypto systems, with no invariant part of the secret, you'd have to hash your entire database of passwords with each nonce to have something to compare with the user's response on every auth, and that's gigantically wasteful.
Now the same thing usernames are used for can be done with PKI DNs, of course. The problem with tokens and keystores is they gather a lot of authorization privileges in one place protected usually by a single... you guessed it... password... which is usually cached to keep the store open (just like passwords if you let your users do that.) Which means the store remains available for any software compromising the client machine much longer than necessary.
Also keystores and tokens are not necessarily well designed... they may leak the public contents of a cert to anyone who can figure out what CA/attributes to challenge with rather than asymmetrically validating the server cert first. That won't grant access, but can be used to track users without their consent.
I personally hate the drive for "passwordless" systems since wetware has some pretty good security properties for those that are capable of using it and I don't think depriving those people of that tool is productive. However, if we are going to use tokens, it would be best to insist the token vendor use auditable OSS hardware/firmware like Nitrokey rather than Yubikey.
Maaaaybe if the Obama admin had actually made it a law instead of reinterpreting existing laws it would have been better?
Maybe if the Republicans who controlled congress hadn't started with "make Obama a 1-term president" as their primary stated goal and pretty much refused anything he put forward whether or not they or their constituents agreed with it or it was good for the country.
Unfortunately the New York Cohen case is still a federal case, just in a different federal district. Perhaps that makes it easier for the state to file charges, I dunno.
That's pretty funny... I stopped listening and didn't renew my payed subscription for the exact opposite reason... they were spending all their time developing apps for everything under the sun, and no time improving their supposed core product, which had stopped finding much new-to-me music I liked no matter how much feedback I put in or how many times I started fresh.
I would say it is your assertion that needs proof. So would anyone else who also studied VLSI design in college.
You are clearly talking out of your ass.
We know how to make secure chips and there are research done in that area.
Yep. But we don't actually follow through on it, nor do consumers demand assurances to that effect, so the point is moot until that changes.
Grab a solar panel and as many old MIPS WRT boxes as you can carry and run for the hills!
YOU are the Developer. It is YOUR obligation to ensure you don't link to bogus, questionable or potentially malicious libraries.
Any library can become bogus and malicious at any given time. One compromised laptop and a keystroke logger to get the DSA key+password is all it takes. I don't think many developers would sign up for a system of "if you write code, you have to stick around and watch that code and all its dependencies vigilantly" because you'd have to stop writing code at age 25 and spend the rest of your life on the full-time job of monitoring what you wrote. The point of volunteer OSS is you are supposed to be able to contribute what you are willing to, when you want to.
Libraries are a double-edged sword security-wise... bugs and compromises in them affect everything, but on the bright side, you only have to fix them in one place, not hunt variants of them down in the thousands. (Not to say that there are not tons of completely redundant libraries due to NIH, megalomania, or just not being aware of other solutions.)
When you see something like TFA happen you need only ask: what work was too menial for anyone to do on a volunteer bases that this was not caught and then you know what the OSS community needs to find someone to pay someone to do.
And now apparently, they'll be able to add such informative categories as "#fml" and "#yolo"