Language Selection

English French German Italian Portuguese Spanish

Security

Security: Intel, Norton, Bug Bounty, Defacements, OnePlus, ICO

Filed under
Security

More on 'Complete and Utter Garbage' From Intel

Filed under
Linux
Security
  • Linux Creator Calls Intel Meltdown, Spectre Patches 'Complete and Utter Garbage'
  • Linux creator slams Intel for crappy Meltdown/Spectre patches

    Intel’s had a (mostly) crappy start to the year, thanks to the revelation of Meltdown and Spectre, two major security flaws affecting a wide range of its processors that are present in hundreds of thousands of devices around the world. It’s working to release fixes for them, but Linux creator Linus Torvalds is not impressed by the company’s efforts.

  • ‘WTF is going on?!’ Linux creator attacks Intel as it retracts ‘garbage’ fix for critical bug

    Patches released by Intel Corp. to fix highly malicious Spectre and Meltdown vulnerabilities affecting its CPUs turned out to be faulty, the company admitted, urging customers to stop installing them until further notice.

    Earlier this month, security researchers at Google Project Zero disclosed that data processed by the majority of modern CPUs, be they desktop computers or smartphones, could be vulnerable to critical exploits they called ‘Spectre’ and ‘Meltdown.’ Tech companies reportedly had months to prepare, and since the public announcement of the vulnerabilities, Intel released at least three patches – before discovering that their fix led some PCs to reboot unexpectedly.

  • Spectre Patches, Snap, Happy Birthday LWN and More

    Are you using protection? Longtime kernel developer, Greg Kroah-Hartman, just posted a simple recipe for users to verify whether they are running a Spectre/Meltdown patched version of the Linux kernel.

  • Intel’s Spectre fixes are ‘complete and utter garbage,’ says Linux inventor

    Linux inventor Linus Torvalds has never been one for diplomacy. He previously said “fuck you” to Nvidia for not supporting Linux, and now Intel has angered him enough to generate some more expletives. In a message to the Linux kernel mailing list on the weekend, Torvalds has expressed his dismay at Intel’s security updates to protect against the major Spectre variant 2 CPU vulnerability. The industry has been scrambling to fix the Meltdown and Spectre vulnerabilities, and the variant 2 of Spectre has been particularly challenging.

Canonical Releases Spectre Patches for Ubuntu Linux, Meltdown Fix for PowerPC

Filed under
Security
Ubuntu

Canonical published today a new set of kernel updates for all of its supported Ubuntu Linux releases that include patches for the Spectre and Meltdown security vulnerabilities.

After pulling Intel's microcode firmware update from the software repositories of Ubuntu 17.10, 16.04 LTS, and 14.04 LTS, Canonical now released the Spectre patches for all supported Ubuntu Linux releases, including all official flavors and those using HWE (Hardware Enablement) kernels, and Meltdown kernel patches for PowerPC (PPC64el) architectures.

Read more

Also: Canonical announces Ubuntu product month for February

Security: TPM, Yubikey, Holes, Bricking and Uber

Filed under
Security
  • Trusted Computing

    The Trusted Platform Module on your computer's motherboard could lead to better security for your Linux system.

    The security of any operating system (OS) layer depends on the security of every layer below it. If the CPU can't be trusted to execute code correctly, there's no way to run secure software on that CPU. If the bootloader has been tampered with, you cannot trust the kernel that the bootloader boots. Secure Boot allows the firmware to validate a bootloader before executing it, but if the firmware itself has been backdoored, you have no way to verify that Secure Boot functioned correctly.

  • Locking the screen when removing a Yubikey

    I have my Yubikey on my key ring, so whenever I leave my computer, I have to remove the Yubikey. So why not lock the screen automatically?

  • Corporate cultural issues hold back secure software development

    The study of over 1,200 IT leaders, conducted by analysts Freeform Dynamics for software company CA Technologies, finds 58 percent of respondents cite existing culture and lack of skills as hurdles to being able to embed security within processes.

  • Stop installing our buggy Spectre CPU firmware fixes, Intel says
  • Uber shrugs off flaw that lets hackers bypass two-factor authentication

    Security researcher Karan Saini found the bug in Uber's two-factor authentication process, which has yet to be rolled out widely to Uber users. The flaw relates to the way an account is authenticated when users log in, meaning hackers [sic] with someone's username and password can drift pass the 2FA with ease.

Security: Gmail, Windows, Allscripts, Android and Browsers

Filed under
Security

Security: Updates and Botched Updates

Filed under
Security
  • Security updates for Monday
  • RedHat reverts patches to mitigate Spectre Variant 2

    RedHat previously released patches to mitigate this issue, however, in a rather controversial move, has decided to roll back these changes after complaints about systems failing to boot with the new patches, and instead is now recommending that, "subscribers contact their CPU OEM vendor to download the latest microcode/firmware for their processor."

  • Red Hat dumps Spectre CPU patches that brick servers

    Enterprise Linux vendor Red Hat will no longer distribute microcode patches to mitigate against the Spectre processor flaw after bugs in the patches stopped user systems from booting up.

    The company advised of its decision late last week after being alerted by its customers to problems with the patches.

    Red Hat is now reverting the microcode_ctl and linux-firmware packages it includes with its enterprise Linux distribution to older versions that are known to be stable.

    Microcode, also known as millicode and firmware, is software distributed by vendors to correct specific errors for processors.

PC desktop build, Intel, spectre issues etc.

Filed under
Hardware
Security

Apart from the initial system bought, most of my systems when being changed were in the INR 20-25k/- budget including all and any accessories I bought later.

The only real expensive parts I purchased have been external hdd ( 1 TB WD passport) and then a Viewsonic 17″ LCD which together sent me back by around INR 10k/- but both seem to give me adequate performance (both have outlived the warranty years) with the monitor being used almost 24×7 over 6 years or so, of course over GNU/Linux specifically Debian. Both have been extremely well value for the money.

As I had been exposed to both the motherboards I had been following those and other motherboards as well. What was and has been interesting to observe what Asus did later was to focus more on the high-end gaming market while Gigabyte continued to dilute it energy both in the mid and high-end motherboards.

Read more

Security: OpenSSL, IoT, and LWN Coverage of 'Intelpocalypse'

Filed under
Security
  • Another Face to Face: Email Changes and Crypto Policy

    The OpenSSL OMC met last month for a two-day face-to-face meeting in London, and like previous F2F meetings, most of the team was present and we addressed a great many issues. This blog posts talks about some of them, and most of the others will get their own blog posts, or notices, later. Red Hat graciously hosted us for the two days, and both Red Hat and Cryptsoft covered the costs of their employees who attended.

    One of the overall threads of the meeting was about increasing the transparency of the project. By default, everything should be done in public. We decided to try some major changes to email and such.

  • Some Basic Rules for Securing Your IoT Stuff

    Throughout 2016 and 2017, attacks from massive botnets made up entirely of hacked [sic] IoT devices had many experts warning of a dire outlook for Internet security. But the future of IoT doesn’t have to be so bleak. Here’s a primer on minimizing the chances that your IoT things become a security liability for you or for the Internet at large.

  • A look at the handling of Meltdown and Spectre

    The Meltdown/Spectre debacle has, deservedly, reached the mainstream press and, likely, most of the public that has even a remote interest in computers and security. It only took a day or so from the accelerated disclosure date of January 3—it was originally scheduled for January 9—before the bugs were making big headlines. But Spectre has been known for at least six months and Meltdown for nearly as long—at least to some in the industry. Others that were affected were completely blindsided by the announcements and have joined the scramble to mitigate these hardware bugs before they bite users. Whatever else can be said about Meltdown and Spectre, the handling (or, in truth, mishandling) of this whole incident has been a horrific failure.

    For those just tuning in, Meltdown and Spectre are two types of hardware bugs that affect most modern CPUs. They allow attackers to cause the CPU to do speculative execution of code, while timing memory accesses to deduce what has or has not been cached, to disclose the contents of memory. These disclosures can span various security boundaries such as between user space and the kernel or between guest operating systems running in virtual machines. For more information, see the LWN article on the flaws and the blog post by Raspberry Pi founder Eben Upton that well describes modern CPU architectures and speculative execution to explain why the Raspberry Pi is not affected.

  • Addressing Meltdown and Spectre in the kernel

    When the Meltdown and Spectre vulnerabilities were disclosed on January 3, attention quickly turned to mitigations. There was already a clear defense against Meltdown in the form of kernel page-table isolation (KPTI), but the defenses against the two Spectre variants had not been developed in public and still do not exist in the mainline kernel. Initial versions of proposed defenses have now been disclosed. The resulting picture shows what has been done to fend off Spectre-based attacks in the near future, but the situation remains chaotic, to put it lightly.

    First, a couple of notes with regard to Meltdown. KPTI has been merged for the 4.15 release, followed by a steady trickle of fixes that is undoubtedly not yet finished. The X86_BUG_CPU_INSECURE processor bit is being renamed to X86_BUG_CPU_MELTDOWN now that the details are public; there will be bug flags for the other two variants added in the near future. 4.9.75 and 4.4.110 have been released with their own KPTI variants. The older kernels do not have mainline KPTI, though; instead, they have a backport of the older KAISER patches that more closely matches what distributors shipped. Those backports have not fully stabilized yet either. KPTI patches for ARM are circulating, but have not yet been merged.

  • Is it time for open processors?

    The disclosure of the Meltdown and Spectre vulnerabilities has brought a new level of attention to the security bugs that can lurk at the hardware level. Massive amounts of work have gone into improving the (still poor) security of our software, but all of that is in vain if the hardware gives away the game. The CPUs that we run in our systems are highly proprietary and have been shown to contain unpleasant surprises (the Intel management engine, for example). It is thus natural to wonder whether it is time to make a move to open-source hardware, much like we have done with our software. Such a move may well be possible, and it would certainly offer some benefits, but it would be no panacea.

    Given the complexity of modern CPUs and the fierceness of the market in which they are sold, it might be surprising to think that they could be developed in an open manner. But there are serious initiatives working in this area; the idea of an open CPU design is not pure fantasy. A quick look around turns up several efforts; the following list is necessarily incomplete.

  • Notes from the Intelpocalypse

    Rumors of an undisclosed CPU security issue have been circulating since before LWN first covered the kernel page-table isolation patch set in November 2017. Now, finally, the information is out — and the problem is even worse than had been expected. Read on for a summary of these issues and what has to be done to respond to them in the kernel.
    All three disclosed vulnerabilities take advantage of the CPU's speculative execution mechanism. In a simple view, a CPU is a deterministic machine executing a set of instructions in sequence in a predictable manner. Real-world CPUs are more complex, and that complexity has opened the door to some unpleasant attacks.

    A CPU is typically working on the execution of multiple instructions at once, for performance reasons. Executing instructions in parallel allows the processor to keep more of its subunits busy at once, which speeds things up. But parallel execution is also driven by the slowness of access to main memory. A cache miss requiring a fetch from RAM can stall the execution of an instruction for hundreds of processor cycles, with a clear impact on performance. To minimize the amount of time it spends waiting for data, the CPU will, to the extent it can, execute instructions after the stalled one, essentially reordering the code in the program. That reordering is often invisible, but it occasionally leads to the sort of fun that caused Documentation/memory-barriers.txt to be written.

Red Hat Patch Warning

Filed under
Red Hat
Security
  • We Didn't Pull CPU Microcode Update to Pass the Buck
  • Red Hat Will Revert Spectre Patches After Receiving Reports of Boot Issues

    Red Hat is releasing updates that are reverting previous patches for the Spectre vulnerability (Variant 2, aka CVE-2017-5715) after customers complained that some systems were failing to boot.

    "Red Hat is no longer providing microcode to address Spectre, variant 2, due to instabilities introduced that are causing customer systems to not boot," the company said yesterday.

    "The latest microcode_ctl and linux-firmware packages are reverting these unstable microprocessor firmware changes to versions that were known to be stable and well tested, released prior to the Spectre/Meltdown embargo lift date on Jan 3rd," Red Had added.

Security: Updates, SOS Fund, IR, ME, and WPA

Filed under
Security
  • Security updates for Friday
  • Seeking SOS Fund Projects

    I’m spending some time over the next few days looking for the next round of projects which might benefit from an SOS Fund security audit.

  • Strong Incident Response Starts with Careful Preparation

    Through working every day with organizations’ incident response (IR) teams, I am confronted with the entire spectrum of operational maturity. However, even in the companies with robust IR functions, the rapidly evolving threat landscape, constantly changing best practices, and surplus of available tools make it easy to overlook important steps during planning. As a result, by the time an incident occurs, it’s too late to improve their foundational procedures.

  • The Intel Management Engine: an attack on computer users' freedom

    Over time, Intel imposed the Management Engine on all Intel computers, removed the ability for computer users and manufacturers to disable it, and extended its control over the computer to nearly 100%. It even has access to the main computer's memory.

  • What Is WPA3, and When Will I Get It On My Wi-Fi?

    WPA2 is a security standard that governs what happens when you connect to a closed Wi-Fi network using a password. WPA2 defines the protocol a router and Wi-Fi client devices use to perform the “handshake” that allows them to securely connect and how they communicate. Unlike the original WPA standard, WPA2 requires implementation of strong AES encryption that is much more difficult to crack. This encryption ensures that a Wi-Fi access point (like a router) and a Wi-Fi client (like a laptop or phone) can communicate wirelessly without their traffic being snooped on.

Syndicate content