This Week In Security: Putty Keys, Libarchive, And Palo Alto

It may be time to rotate some keys. The venerable PuTTY was updated to 0.81 this week, and the major fix was a change to how ecdsa-sha2-nistp521 signatures are generated. The problem was reported on the oss-security mailing list, and it’s quite serious, though thankfully with a somewhat narrow coverage.

The PuTTY page on the vulnerability has the full details. To understand what’s going on, we need to briefly cover ECDSA, nonces, and elliptic curve crypto. All cryptography depends on one-way functions. In the case of RSA, it’s multiplying large primes together. The multiplication is easy, but given just the final result, it’s extremely difficult to find the two factors. DSA uses a similar problem, the discrete logarithm problem: raising a number to a given exponent, then doing modulo division.

Yet another cryptography primitive is the elliptic curve, which uses point multiplication as the one-way function. I’ve described it as a mathematical pinball, bouncing around inside the curve. It’s reasonably easy to compute the final point, but essentially impossible to trace the path back to the origin. Formally this is the Elliptic Curve Discrete Logarithm Problem, and it’s not considered to be quantum-resistant, either.

One of the complete schemes is ECDSA, which combines the DSA scheme with Elliptic Curves. Part of this calculation uses a nonce, denoted “k”, a number that is only used once. In ECDSA, k must be kept secret, and any repetition of different messages with the same nonce can lead to rapid exposure of the secret key.

And now we get to PuTTY, which was written for Windows back before that OS had any good cryptographic randomness routines. As we’ve already mentioned, re-use of k, the nonce, is disastrous for DSA. So, PuTTY did something clever, and took the private key and the contents of the message to be signed, hashed those values together using SHA-512, then used modulo division to reduce the bit-length to what was needed for the given k value. The problem is the 521-bit ECDSA, which takes a 521-bit k. That’s even shorter than the output of a SHA-512, so the resulting k value always started with nine 0 bits. Continue reading “This Week In Security: Putty Keys, Libarchive, And Palo Alto”

FLOSS Weekly Episode 779: Errata Prevention Specialist

This week Jonathan Bennett and Dan Lynch sit down with Andy Stewart to talk about Andy’s Ham Radio Linux (AHRL)! It’s the Linux distro designed to give hams the tools they need to work with their radios. What’s it like to run a niche Linux distro? How has Andy managed to keep up with this for over a decade? And what’s the big announcement about the project breaking today?

Continue reading “FLOSS Weekly Episode 779: Errata Prevention Specialist”

This Week In Security: BatBadBut, DLink, And Your TV Too

So first up, we have BatBadBut, a pun based on the vulnerability being “about batch files and bad, but not the worst.” It’s a weird interaction between how Windows uses cmd.exe to execute batch files and how argument splitting and character escaping normally works. And what is apparently a documentation flaw in the Windows API.

When starting a process, even on Windows, the new executable is handed a set of arguments to parse. In Linux and friends, that is a pre-split list of arguments, the argv array. On Windows, it’s a single string, left up to the program to handle. The convention is to follow the same behavior as Linux, but the cmd.exe binary is a bit different. It uses the carrot ^ symbol instead of the backslash \ to escape special symbols, among other differences. The Rust devs took a look and decided that there are some cases where a given string just can’t be made safe for cmd.exe, and opted to just throw an error when a string met this criteria.

And that brings us to the big questions. Who’s fault is it, and how bad is it? I think there’s some shared blame here. The Microsoft documentation on CreateProcess() strongly suggests that it won’t execute a batch file without cmd.exe being explicitly called. On the other hand, This is established behavior, and scripting languages on Windows have to play the game by Microsoft’s rules. And the possible problem space is fairly narrow: Calling a batch file with untrusted arguments.

Almost all of the languages with this quirk have either released patches or documentation updates about the issue. There is a notable outlier, as the Java language will not receive a fix, not deeming it a vulnerability. It’s rather ironic, given that Java is probably the most likely language to actually find this problem in the wild. Continue reading “This Week In Security: BatBadBut, DLink, And Your TV Too”

FLOSS Weekly Episode 778: OctoPrint — People Are Amazing At Breaking Things

This week Jonathan Bennett and Katherine Druckman sit down with Gina Häußge to talk OctoPrint! It’s one of our favorite ways to babysit our 3D printers, and the project has come a long way in the last 12 years! It’s a labor of love, primarily led by Gina, who has managed to turn it into a full time job. Listen in to hear that story and more, including how to run an Open Source project without losing your sanity, why plugins are great, and how to avoid adding a special services employee as a co-maintainer!

Continue reading “FLOSS Weekly Episode 778: OctoPrint — People Are Amazing At Breaking Things”

This Week In Security: XZ, ATT, And Letters Of Marque

The xz backdoor is naturally still the top story of the week. If you need a refresher, see our previous coverage. As expected, some very talented reverse engineers have gone to work on the code, and we have a much better idea of what the injected payload does.

One of the first findings to note is that the backdoor doesn’t allow a user to log in over SSH. Instead, when an SSH request is signed with the right authentication key, one of the certificate fields is decoded and executed via a system() call. And this makes perfect sense. An SSH login leaves an audit trail, while this backdoor is obviously intended to be silent and secret.

It’s interesting to note that this code made use of both autotools macros, and the GNU ifunc, or Indirect FUNCtions. That’s the nifty feature where a binary can include different versions of a function, each optimized for a different processor instruction set. The right version of the function gets called at runtime. Or in this case, the malicious version of that function gets hooked in to execution by a malicious library. Continue reading “This Week In Security: XZ, ATT, And Letters Of Marque”

FLOSS Weekly Episode 777: Asterisk — Wait, Faxes?

This week Jonathan Bennett and David Ruggles sit down with Joshua Colp to talk about Asterisk! That’s the Open Source phone system software you already interact with without realizing it. It started as a side project to run the phones for Linux Support Services, and it turned out working on phone systems was more fun than supporting Linux. The project grew, and in the years since has landed at Sangoma, where Joshua holds the title of Asterisk Project Lead.

Asterisk is used in call centers, business phone systems, and telecom appliances around the world. But how does it handle faxes, WebRTC, and stopping spam calls? Just kidding on that last one, still an unsolved problem.

Continue reading “FLOSS Weekly Episode 777: Asterisk — Wait, Faxes?”

Security Alert: Potential SSH Backdoor Via Liblzma

In breaking news that dropped just after our weekly security column went live, a backdoor has been discovered in the xz package, that could potentially compromise SSH logins on Linux systems. The most detailed analysis so far seems to be by [Andres Freund] on the oss-security list.

The xz release tarballs from 5.6.0 in late February and 5.6.1 on March 9th both contain malicious code. A pair of compressed files in the repository contain the majority of the malicious patch, disguised as test files. In practice, this means that looking at the repository doesn’t reveal anything amiss, but downloading the release tarballs gives you the compromised code.

This was discovered because SSH logins on a Debian sid were taking longer, with more CPU cycles than expected. And interestingly, Valgrind was throwing unexpected errors when running on the liblzma library. That last bit was first discovered on February 24th, immediately after the 5.6.0 release. The xz-utils package failed its tests on Gentoo builds.

Continue reading “Security Alert: Potential SSH Backdoor Via Liblzma”