Such a quick turnaround between private and public disclosure means one of two things.
First possibility: They're not interested in responsible disclosure. Likely. As others have pointed out, they get more noise for their findings this way.
Second possibility: They know these vulnerabilities are being actively exploited. Not as likely, but a real possibility, and way more worrying.
They are on to something, but have it *completely* backwards. Learning to code has never been easier. At the same time, using a computer has become much much easier as well. Part of the barrier to entry of older computers was the need to know something about the computer. That barrier to entry has been removed, and people aren't learning about the machines they're using.
I don't know what the answer is. It doesn't seem correct to intentionally make computers harder to use. Perhaps moving away from the mindset that a computer is an appliance *looks at Apple significantly* would be a decent place to start.
but the video binary blob is closed source so are other parts.
So there is closed firmware for the wifi and potentially video chips, yes. There is an open source video driver now, that works fairly well.
So if you take the Fedora/kernel view of things, totally open source friendly. If you take the libreboot/FSF/Purism Librem, then yeah, not what you want.
After political correctness has subjugated humanity, it sets its sights on the machines! I take some small comfort in knowing that it can never actually change reality itself. Even if no one is allowed to notice, the world will continue following the laws of physics.
I tried OpenWRT on a cheap TP-LINK wifi router. While the feature set was impressive, it could barely manage 1/3 the throughput of the stock firmware.
This is absolutely accurate. The reason is that the stock firmware enables hardware accelerated NAT in the switch chip. This isn't yet supported in the Linux kernel, so no support in Openwrt.
Once actively exploited, the proper response is to publicly announce the exploit. This is standard and acceptable practice. Someone is grinding an anti-google axe on this non-story.
When I first read this on Phoronix, it appeared that systemd was replacing the mount command. This is not the case. It is wrapping the mount command. That seems to be an important distinction. Replacing mount would be crazy and pointless. Handling mounts more intelligently during startup would be welcome. So far, this seems to be the latter instead of the former.
Well, this is a virtual machine they're eavesdropping on. Anyone running something on a virtual machine should always assume that the one controlling the underlying hardware can always see everything that's happening on the VMs too. My view has always been that if I don't have the physical hardware before my eyes, I have no real guarantee someone isn't tampering with it either legally or illegally. Heck, even if it's before my eyes, someone may still have tampered with it at some point in time, or even remotely.
Exactly this. If you don't control the bare metal, then the VM isn't fully trustworthy. Even before the details of the attack were worked out, this should have been an obvious conclusion.
Yay, totally filled with executive types that have no actual clue about computer security. Maybe if there were actual security researchers, hackers, and programmers working on the problem... Wait, we already are working on it, and still no silver bullets.
I use Ardour on Fedora, connected to a Focusrite Saffire Pro 40, and heavily using the great and opensource Calf Studio Gear Audio plugin suite. Everything works really well, and the setup could be used to put together a really high quality album. We almost exclusively use it for recording church services, which doesn't exercise the full potential of the setup. One of these days I'll have time to put together a project that takes advantage of more of the capabilities we have.
This is a very good point. The question is, is any of the stock firmware covered by GPLv3? Linux kernel is GPLv2, which does not have the tivoization clause.
I grant you that the ability exists on many SoCs. What remains to be seen is whether TP-Link has actually done the secure-boot chain starting with the SoC. If one of the OpenWrt devs could get their hands on one of these locked down devices, we'd find out pretty quickly. I still suspect it's just a check in the stock firmware's web interface.
These routers use UBoot, not a bootloader baked into the SoC. I doubt they have done anything too fancy, probably just checking for signed firmware when the user uploads it. I would suspect that even just using a serial connection to interrupt uboot would be enough to circumvent the checking. We won't know for sure until somebody does a complete evaluation/reverse-engineer of it.
I saw the presentation at the OpenWrt Summit, and I got excited. I can't buy 10,000 units, but I'll probably start installing these by default wherever I can, assuming I can my hands on some at a price that works. I know I will run one at my house. =)
Seems like a self-correcting problem, given enough time. Giving pedestrians the right-away seems like a problematic policy. It sounds nice, but physics suggests that a pedestrian can overcome their momentum and come to an immediate stop more successfully than a motor vehicle, which further suggests that perhaps the pedestrian should stop and wait, rather than the cars.
Port knocking is one way to avoid being a target of ssh attacks, but legacy port knocking has its own shortcomings. SPA (Single Packet Auth) has solved most of those problems. Fwknop is the only maintained spa implamentation that I know of. More info at https://www.cipherdyne.org/fwk...
Not so much. https://en.wikipedia.org/w/ind... seems to be the edit that showed up on Google. It was up for a week before fixed.
Such a quick turnaround between private and public disclosure means one of two things.
First possibility: They're not interested in responsible disclosure. Likely. As others have pointed out, they get more noise for their findings this way.
Second possibility: They know these vulnerabilities are being actively exploited. Not as likely, but a real possibility, and way more worrying.
They are on to something, but have it *completely* backwards. Learning to code has never been easier. At the same time, using a computer has become much much easier as well. Part of the barrier to entry of older computers was the need to know something about the computer. That barrier to entry has been removed, and people aren't learning about the machines they're using.
I don't know what the answer is. It doesn't seem correct to intentionally make computers harder to use. Perhaps moving away from the mindset that a computer is an appliance *looks at Apple significantly* would be a decent place to start.
great as far as it goes
but the video binary blob is closed source
so are other parts.
So there is closed firmware for the wifi and potentially video chips, yes. There is an open source video driver now, that works fairly well.
So if you take the Fedora/kernel view of things, totally open source friendly. If you take the libreboot/FSF/Purism Librem, then yeah, not what you want.
By far, my favorite hardware to work with is the Raspberry Pi 3. It now works with mainline Linux, and has a bunch of gpio to play with.
After political correctness has subjugated humanity, it sets its sights on the machines! I take some small comfort in knowing that it can never actually change reality itself. Even if no one is allowed to notice, the world will continue following the laws of physics.
Is this the first of Slashdot's April Fools posts? It's getting harder to tell.
Exactly correct. The right to repair is a blatantly obvious ramification of ownership rights.
For what is essentially attempted murder?
Absolutely correct, this is attempted murder, and should be handled as such by the legal system.
I tried OpenWRT on a cheap TP-LINK wifi router. While the feature set was impressive, it could barely manage 1/3 the throughput of the stock firmware.
This is absolutely accurate. The reason is that the stock firmware enables hardware accelerated NAT in the switch chip. This isn't yet supported in the Linux kernel, so no support in Openwrt.
With news like this, suddenly the Irish will be interested in their own Brexit.
reviewing non-dup emails is hard.
Once actively exploited, the proper response is to publicly announce the exploit. This is standard and acceptable practice. Someone is grinding an anti-google axe on this non-story.
When I first read this on Phoronix, it appeared that systemd was replacing the mount command. This is not the case. It is wrapping the mount command. That seems to be an important distinction. Replacing mount would be crazy and pointless. Handling mounts more intelligently during startup would be welcome. So far, this seems to be the latter instead of the former.
Well, this is a virtual machine they're eavesdropping on. Anyone running something on a virtual machine should always assume that the one controlling the underlying hardware can always see everything that's happening on the VMs too. My view has always been that if I don't have the physical hardware before my eyes, I have no real guarantee someone isn't tampering with it either legally or illegally. Heck, even if it's before my eyes, someone may still have tampered with it at some point in time, or even remotely.
Exactly this. If you don't control the bare metal, then the VM isn't fully trustworthy. Even before the details of the attack were worked out, this should have been an obvious conclusion.
Yay, totally filled with executive types that have no actual clue about computer security. Maybe if there were actual security researchers, hackers, and programmers working on the problem... Wait, we already are working on it, and still no silver bullets.
I use Ardour on Fedora, connected to a Focusrite Saffire Pro 40, and heavily using the great and opensource Calf Studio Gear Audio plugin suite. Everything works really well, and the setup could be used to put together a really high quality album. We almost exclusively use it for recording church services, which doesn't exercise the full potential of the setup. One of these days I'll have time to put together a project that takes advantage of more of the capabilities we have.
This is a very good point. The question is, is any of the stock firmware covered by GPLv3? Linux kernel is GPLv2, which does not have the tivoization clause.
I grant you that the ability exists on many SoCs. What remains to be seen is whether TP-Link has actually done the secure-boot chain starting with the SoC. If one of the OpenWrt devs could get their hands on one of these locked down devices, we'd find out pretty quickly. I still suspect it's just a check in the stock firmware's web interface.
These routers use UBoot, not a bootloader baked into the SoC. I doubt they have done anything too fancy, probably just checking for signed firmware when the user uploads it. I would suspect that even just using a serial connection to interrupt uboot would be enough to circumvent the checking. We won't know for sure until somebody does a complete evaluation/reverse-engineer of it.
I'm still on barrier breaker; my router isn't supported by chaos calmer (yet)?
If there's a flaw in the older version... I'm pretty much in the same boat as any one with default firmware would be.
What hardware do you have that isn't supported?
This is why the ability to install secure and Open Source firmware like OpenWrt is so important.
https://openwrt.org/
I saw the presentation at the OpenWrt Summit, and I got excited. I can't buy 10,000 units, but I'll probably start installing these by default wherever I can, assuming I can my hands on some at a price that works. I know I will run one at my house. =)
Seems like a self-correcting problem, given enough time.
Giving pedestrians the right-away seems like a problematic policy. It sounds nice, but physics suggests that a pedestrian can overcome their momentum and come to an immediate stop more successfully than a motor vehicle, which further suggests that perhaps the pedestrian should stop and wait, rather than the cars.
Port knocking is one way to avoid being a target of ssh attacks, but legacy port knocking has its own shortcomings. SPA (Single Packet Auth) has solved most of those problems. Fwknop is the only maintained spa implamentation that I know of. More info at https://www.cipherdyne.org/fwk...