Fortinet, the global cybersecurity leader driving the convergence of networking and security, today announced FortiSP5, the latest breakthrough in ASIC technology from Fortinet, propelling major leaps forward in securing distributed network edges. Building on over 20 years of ASIC investment and innovation from Fortinet, FortiSP5 delivers significant secure computing power advantages over traditional CPU and network ASICs, lower cost and power consumption, the ability to enable new secure infrastructure across branch, campus, 5G, edge compute, operational technologies, and more.

"With the introduction of FortiSP5, Fortinet once again sets new industry records for performance, cost, and energy efficiency. As the only cybersecurity vendor leveraging purpose-built ASICs, an over 20-year investment in innovation, Fortinet delivers the secure computing power that will support the next generation of secure infrastructure." Ken Xie, Founder, Chairman of the Board, and Chief Executive Officer at Fortinet

Red Hat Systemd (system and service manager) lead developer Lennart Poettering discovered that AMD A6-6310 "Beema" SoC that's popular among low-cost notebooks, has a faulty implementation of the RdRand random-number generation instruction. The processor's hardware random number generator (RNG) loses "randomness" after the machine resumes from a suspended state (i.e. waking up the notebook from sleep by opening its lid while it's powered on). Modern computers rely on RNGs for "entropy," critical to generation of unpredictable keys on the fly for SSL. However, the entropy source needn't be hardware, and isn't so by default. Software RNGs exist, and by default the Linux kernel does not use RdRand to generate entropy. Windows is not known to use RdRand for basic ACPI functions such as suspend/resume; however a faulty hardware RNG is not without implications for the platform, and applications that run on it.

Users on GitHub and Bugzilla report that with this bug, you cannot make a machine suspend a second time after waking it up from a suspended state, if your kernel uses RdRand. Commit cc83d51 to Systemd introduced optional randomness generation based on RdRand instruction. So, if RdRand instruction is present, it is used to generate UUIDs for invocation IDs. Michael Larabel of Phoronix comments that the RdRand bug is only found on older generations of AMD processors, "Excavator" and older; and does not affect the latest "Zen" processors. This bug report chronicles what's wrong with RdRand on the affected processors, as does this Linux kernel bugzilla thread. By avoiding RdRand usage on the system as part of generating a UUID, the reported systemd issue no longer happens. Red Hat is working on a solution to this bug.

A Malwarebytes report calls attention to the latest occurrence in the inevitable trend that that ensues a particular security vulnerability being given coverage by the media. As users' attention to the vulnerability is heightened, so is their search for a solution, for a way to reduce the risk of exposition. Hence, users search for patches; and hence, some fake patches surface that take advantage of the more distracted, or less informed, of those who really just want to be left at peace.

Case in point: Malwarebytes has identified a recently-registered domain that is particularly targeting German users (remember: you can be next; it's just a matter of Google translating the page for it be targeting you as well). The website is offering an information page with various links to external resources about Meltdown and Spectre and how it affects processors, and is affiliated with the German Federal Office for Information Security (BSI) - all good, right?

Another week, yet another security bulletin in tech news, with yet another vulnerability that joins the fray of both Intel's meltdown and Western Digital's MyCloud hacks. A team of researchers recently wrote a paper they titled "Return Of Bleichenbacher's Oracle Threat (ROBOT)". This paper went on to show how a well-known, circa 1998 exploit is still a viable way to take advantage of websites of even big name companies and services, such as Facebook and PayPal (in total, around 2.8% of the top 1 million sites also tested positive). The ROBOT exploit, a critical, 19-year-old vulnerability that allows attackers to decrypt encrypted data and sign communications using compromised sites' secret encryption key, is still valid. Only, it's 19 years later.

The heart of the issue stems from a vulnerability that was discovered in 1998 by researcher Daniel Bleichenbacher, who found the vulnerability in the TLS predecessor known as secure sockets layer. The attack is dubbed an Oracle threat because attackers can write specialized queries to which the websites and affected systems respond with "Yes" or "No"; as such, it's possible, given enough time, for attackers to build up the amount of disclosed sensitive information and get a clear picture of the protected data. To the flaw's discovery by Bleichenbacher, SSL architects apparently responded in a B-movie type of way, which nevertheless might have been needed to keep all systems green: by designing workarounds on top of workarounds, rather than removing or rewriting the faulty RSA algorithm.