|
|
Subscribe / Log in / New account

Brief items

Security

"KRACK": a severe WiFi protocol flaw

The "krackattacks" web site discloses a set of WiFi protocol flaws that defeat most of the protection that WPA2 encryption is supposed to provide. "In a key reinstallation attack, the adversary tricks a victim into reinstalling an already-in-use key. This is achieved by manipulating and replaying cryptographic handshake messages. When the victim reinstalls the key, associated parameters such as the incremental transmit packet number (i.e. nonce) and receive packet number (i.e. replay counter) are reset to their initial value. Essentially, to guarantee security, a key should only be installed and used once. Unfortunately, we found this is not guaranteed by the WPA2 protocol".

Comments (42 posted)

Green: Falling through the KRACKs

Matthew Green explores the origins of the KRACK vulnerability. "I don’t want to spend much time talking about KRACK itself, because the vulnerability is pretty straightforward. Instead, I want to talk about why this vulnerability continues to exist so many years after WPA was standardized. And separately, to answer a question: how did this attack slip through, despite the fact that the 802.11i handshake was formally proven secure?"

Comments (5 posted)

Tips to Secure Your Network in the Wake of KRACK (Linux.com)

Konstantin Ryabitsev argues on Linux.com that WiFi security is only a part of the problem. "Wi-Fi is merely the first link in a long chain of communication happening over channels that we should not trust. If I were to guess, the Wi-Fi router you’re using has probably not received a security update since the day it got put together. Worse, it probably came with default or easily guessable administrative credentials that were never changed. Unless you set up and configured that router yourself and you can remember the last time you updated its firmware, you should assume that it is now controlled by someone else and cannot be trusted."

Comments (5 posted)

Bottomley: Using Elliptic Curve Cryptography with TPM2

James Bottomley describes the use of the trusted platform module with elliptic-curve cryptography, with a substantial digression into how the elliptic-curve algorithm itself works. "The initial attraction is the same as for RSA keys: making it impossible to extract your private key from the system. However, the mathematical calculations for EC keys are much simpler than for RSA keys and don’t involve finding strong primes, so it’s much simpler for the TPM (being a fairly weak calculation machine) to derive private and public EC keys."

Comments (13 posted)

Millions of high-security crypto keys crippled by newly discovered flaw (Ars Technica)

Ars Technica is reporting on a flaw in the RSA library developed by Infineon that drastically reduces the amount of work needed to discover a private key from its corresponding public key. This flaw, dubbed "ROCA", mainly affects key pairs that have been generated on keycards. "While all keys generated with the library are much weaker than they should be, it's not currently practical to factorize all of them. For example, 3072-bit and 4096-bit keys aren't practically factorable. But oddly enough, the theoretically stronger, longer 4096-bit key is much weaker than the 3072-bit key and may fall within the reach of a practical (although costly) factorization if the researchers' method improves. To spare time and cost, attackers can first test a public key to see if it's vulnerable to the attack. The test is inexpensive, requires less than 1 millisecond, and its creators believe it produces practically zero false positives and zero false negatives. The fingerprinting allows attackers to expend effort only on keys that are practically factorizable. The researchers have already used the method successfully to identify weak keys, and they have provided a tool here to test if a given key was generated using the faulty library. A blog post with more details is here."

Comments (31 posted)

ACME Support in Apache HTTP Server Project

Let's Encrypt has announced that Automatic Certificate Management Environment (ACME) protocol support is being integrated into the Apache HTTP Server (httpd). "ACME support being built in to one of the world’s most popular Web servers, Apache httpd, is great because it means that deploying HTTPS will be even easier for millions of websites. It’s a huge step towards delivering the ideal certificate issuance and management experience to as many people as possible."

Comments (2 posted)

Security quotes of the week

Multiple protocols are used to generate a secure encryption key for a Wi-Fi network. We already knew that most common one, the Wi-Fi password, is insecure against a nearby attacker. A proximate attacker can listen for the "handshake,"–the agreement process between the access point and the client. Then, the attacker can use that information to launch a "brute force" attack, trying as many passwords as necessary until a check against the captured information shows the guess is correct.

So unless your Wi-Fi password looks something like a cat's hairball (e.g. ":SNEIufeli7rc"–which is not guessable with a few million tries by a computer), a local attacker had the capability to determine the password, decrypt all the traffic, and join the network before KRACK.

Nicholas Weaver

But the situation is critical. The Internet is dangerous -- and the IoT gives it not just eyes and ears, but also hands and feet. Security vulnerabilities, exploits, and attacks that once affected only bits and bytes now affect flesh and blood.

Markets, as we've repeatedly learned over the past century, are terrible mechanisms for improving the safety of products and services. It was true for automobile, food, restaurant, airplane, fire, and financial-instrument safety. The reasons are complicated, but basically, sellers don't compete on safety features because buyers can't efficiently differentiate products based on safety considerations. The race-to-the-bottom mechanism that markets use to minimize prices also minimizes quality. Without government intervention, the IoT remains dangerously insecure.

Bruce Schneier

Comments (1 posted)

Kernel development

Kernel release status

The current development kernel is 4.14-rc5, released on October 15. Linus said: "We've certainly had smaller rc5's, but we've had bigger ones too, and this week finally felt fairly normal in a release that has up until now felt a bit messier than it perhaps should have been. So assuming this trend holds, we're all good. Knock wood."

The October 15 4.14 regression report lists nine known problems.

Stable updates: 4.13.6, 4.9.55, 4.4.92, and 3.18.75 were released on October 12; 4.9.56 followed immediately thereafter to fix a networking bug that slipped into 4.9.55. 4.13.7 came out on October 14 with an important security fix. Finally, 4.13.8, 4.9.57, 4.4.93, and 3.18.76 were released on October 18.

Comments (none posted)

An enforcement clarification from the kernel community

The Linux Foundation's Technical Advisory board, in response to concerns about exploitative license enforcement around the kernel, has put together this patch adding a document to the kernel describing its view of license enforcement. This document has been signed or acknowledged by a long list of kernel developers. In particular, it seeks to reduce the effect of the "GPLv2 death penalty" by stating that a violator's license to the software will be reinstated upon a timely return to compliance. "We view legal action as a last resort, to be initiated only when other community efforts have failed to resolve the problem. Finally, once a non-compliance issue is resolved, we hope the user will feel welcome to join us in our efforts on this project. Working together, we will be stronger."

See this blog post from Greg Kroah-Hartman for more information.

Comments (18 posted)

Quote of the week

The other thing perhaps worth mentioning is how much random fuzzing people are doing, and it's finding things. We've always done fuzzing (who remembers the old "crashme" program that just generated random code and jumped to it? We used to do that quite actively very early on), but people have been doing some nice targeted fuzzing of driver subsystems etc, and there's been various fixes (not just this last week either) coming out of those efforts. Very nice to see.
Linus Torvalds

Comments (2 posted)

Distributions

DragonFly BSD 5.0

DragonFly BSD 5.0 has been released. "Preliminary HAMMER2 support has been released into the wild as-of the 5.0 release. This support is considered EXPERIMENTAL and should generally not yet be used for production machines and important data. The boot loader will support both UFS and HAMMER2 /boot. The installer will still use a UFS /boot even for a HAMMER2 installation because the /boot partition is typically very small and HAMMER2, like HAMMER1, does not instantly free space when files are deleted or replaced. DragonFly 5.0 has single-image HAMMER2 support, with live dedup (for cp's), compression, fast recovery, snapshot, and boot support. HAMMER2 does not yet support multi-volume or clustering, though commands for it exist. Please use non-clustered single images for now."

Comments (1 posted)

Distribution quote of the week

On Mon, Oct 16, 2017 at 11:00:05AM +0200, Martin Stransky wrote:
> Sure, out of box thinking is not expected here and Vogons could take
> lessons from our council members ;-)

Just wait until you see our poetry!

In seriousness, out-of-the-box thinking should be *encouraged* — but please in the the future make sure to communicate and double-check with others, because we care about our users quite a bit more than Vogons do.

Matthew Miller

Comments (none posted)

Development

Ruiz: Fleet Commander: production ready!

Alberto Ruiz announces that Fleet Commander is ready for production use. "Fleet Commander is an integrated solution for large Linux desktop deployments that provides a configuration management interface that is controlled centrally and that covers desktop, applications and network configuration. For people familiar with Group Policy Objects in Active Directory in Windows, it is very similar."

Comments (none posted)

Development quotes of the week

One regression fix since 1.19.4 (mea culpa), and fixes for CVEs 2017- 12176 through 2017-12187. C is a terrible language, please stop writing code in it.
Adam Jackson (releases xorg-server 1.19.5)

If I had a magic wand, I would use it to find all of the -1 reviews in gerrit for typos, wording clarifications, markup corrections, variable naming disagreements, and other minor issues and turn them into +1/+2 votes with a follow-up patch from the reviewer to fix the problems.
Doug Hellmann

My father spent from 57 to 83 on his five acres on a hilltop. He puttered in his ham shack. He ran for county planning commissioner and lost. He cared for my aging mother. He never wrote another line of code.

Part of that is on him (about which more later), but part is on the system you and I are still part of. The beliefs that prevent experienced programmers from contributing at their full capacity are still out there. It’s up to us to call them out.

Kent Beck (Thanks to Paul Wise)

Comments (none posted)

Page editor: Jake Edge
Next page: Announcements>>


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds