Intel's zero-day problem

Posted May 3, 2017 23:06 UTC (Wed) by raven667 (subscriber, #5198)
In reply to: Intel's zero-day problem by mikemol
Parent article: Intel's zero-day problem

I would expand this point to make the general assertion that devices modern enough to have IPv6 stacks, esp. if running Linux or *BSD, are also modern enough to have built in packet filters as you describe, and so should be built with the capability of handling these kind of problem all by themselves. The problems that firewalls were originally designed for, by DEC back in the early IPv4 days, were a lot of deployed devices with no packet filters, non-random TCP initial sequence numbers, no SYN-cookies, no cryptographic authentication where TCPWrappers was a major innovation, that's not the world we have today, we have relatively more robust TCP, widely deployed cryptographic authentication/transport, built-in high quality packet filters and should raise the bar correspondingly to our current security capabilities.

Intel's zero-day problem

Posted May 3, 2017 23:15 UTC (Wed) by mikemol (guest, #83507) [Link] (2 responses)

No host-local firewall will protect you from your hardware siphoning off and diverting packets.

The firewall I described belongs on the network gateway. (In addition to the host.)

Intel's zero-day problem

Posted May 5, 2017 15:55 UTC (Fri) by raven667 (subscriber, #5198) [Link] (1 responses)

I was thinking local to the embedded host, in this case the OS running on the AMT CPU that is exposed to the Internet, not the OS running on the main CPU. If you don't control security policy on the BMC/AMT device then sure, you need some external device to enforce policy, but we shouldn't be building devices that don't allow the owner to control basic access and auth. The point I'm trying to get across is that whatever embedded software is used in the network thing, it probably is capable of supporting basic access and auth control on its own, if we choose to enable the feature and build the interface to control it. How hard would it really be to provide an interface for the device owner to put in a few stateless netfilter rules on the AMT/BMC, and use the same authentication protocols that defend our main systems from Internet-scale attackers.

Intel's zero-day problem

Posted May 9, 2017 5:30 UTC (Tue) by ringerc (subscriber, #3071) [Link]

Right. It's more like some appliance or IoT device than a real host, and should be treated with the same extreme dubiousness about its security and trustworthiness.

Intel's zero-day problem

Posted May 9, 2017 5:26 UTC (Tue) by ringerc (subscriber, #3071) [Link] (3 responses)

Actually, I think with the IoT "revolution" we're right back there again.

Pathetically insecure devices that never get security audits or updates. That have no user or admin configurability or documentation. Devices hacked together by a rushed team adapting a related product's code in a single 36-hour sprint to try to beat a competitor to market, before completely forgetting about it.

Devices where if you're lucky you might be able to update or fix them with a vendor-pushed remote firmware update (assuming an attacker doesn't abuse the inevitably insecure mechanism instead). Or with a soldering iron to access pads for USB-serial, RS232, or even JTAG. Occasionally you'll have a webui to upload a firmware blob. But your chances of actually fixing anything without the vendor supplying a canned update image are nearly nil.

The more that these seething piles of crap can be hidden from the rest of the Internet, the better.

Intel's zero-day problem

Posted May 10, 2017 16:17 UTC (Wed) by raven667 (subscriber, #5198) [Link]

> Actually, I think with the IoT "revolution" we're right back there again.
> Pathetically insecure devices that never get security audits or updates

I think you are right and its frustrating because unlike in the past, where the technology to secure devices wasn't built yet, people building IoT devices are taking tools which have access control, auth, etc. available and turning those features off, making by their action something reasonably secure, pathetic. In the same way that SSH raised the bar for default remote access/admin we need the same kind of effort to make the defaults for these kind of embedded devices reasonably decent. Basic netfilter rules and key-based auth using widely audited tools, could make these kinds of devices secure against the kind of wholesale attacks we are seeing.

Intel's zero-day problem

Posted May 12, 2017 6:37 UTC (Fri) by if.gnu.linux (guest, #88877) [Link] (1 responses)

> Devices hacked together by a rushed team adapting a related product's code in a single 36-hour sprint to try to beat a competitor to market, before completely forgetting about it.

I think that there are two other sides we have to consider.

The first one is we as consumers are 'guilty' for always demanding new products which are more speedy, have more RAM etc. and for replacing one year old devices with new ones.

The second one is softwares need more RAM, more GPU power etc. to run. I think software developers think that "Nowadays a device has 4 GB RAM so what is wrong if my application use 1 GB of that RAM."

Intel's zero-day problem

Posted May 12, 2017 11:16 UTC (Fri) by pizza (subscriber, #46) [Link]

> The second one is softwares need more RAM, more GPU power etc. to run. I think software developers think that "Nowadays a device has 4 GB RAM so what is wrong if my application use 1 GB of that RAM."

Note that it is often *cheaper* to put more RAM in the device than less.