This Week In Security: Malicious Clipboards, Snakes On A Domain, And Binary Golf

September 2, 2022 by 4 Comments

There’s a bit of a panic regarding Chromium, Google Chrome, the system clipboard, and of all things, Google Doodles on the New Tab Page. It’s all about Chromium issue 1334203, “NewTabPageDoodleShareDialogFocusTest.All test fails when user gesture is enforced”. You see, Chromium has quite a large regression test suite, and Google engineers want to ensure that the Google Doodles always work. A security feature added to the clipboard handling API happened to break a Doodles test, so to fix the Doodle, the security feature was partially reverted. The now-missing feature? Requiring user interaction before a page can read or write to the clipboard.

Now you understand why there’s been a bit of a panic — yes, that sounds really bad. Pages arbitrarily reading from your clipboard is downright malicious and dangerous. And if no interaction is required, then any page can do so, right? No, not quite. So, Chrome has a set of protections, that there are certain things that a page cannot do if the user has not interacted with the page. You might see this at play in Discord when trying to refresh a page containing a video call. “Click anywhere on this page to enable video.” It’s intended to prevent annoying auto-play videos and other irritating page behavior. And most importantly, it’s *not* the only protection against a page reading your clipboard contents. See for yourself. Reading the clipboard is a site permission, just like accessing your camera or mic.

Now it’s true that a site could potentially *write* to the clipboard, and use this to try to be malicious. For example, writing rm -rf / on a site that claims to be showing off Linux command line tips. But that’s always been the case. It’s why you should always paste into a simple text editor, and not straight into the console from a site. So, really, no panic is necessary. The Chromium devs tried to roll out a slightly more aggressive security measure, and found it broke something unrelated, so partially rolled it back. The sky is not falling.
Continue reading “This Week In Security: Malicious Clipboards, Snakes On A Domain, And Binary Golf” →

This Week In Security: Text Rendering On Windows, GNU Poke, And Bitsquatting

March 5, 2021 by 27 Comments

Project Zero just unrestricted the details on CVE-2021-24093, a potentially nasty vulnerability in Windows 10’s DirectWrite, a text rendering library. The flaw got fixed in this month’s patch Tuesday roundup. The flaw is accessible in all the major browsers on Windows 10, as they use DirectWrite for font rendering. The trick here is to use a malicious font that uses some nonsense values. Those values result in a buffer allocation that is too small for complex characters such as Æ.

Because the vulnerability is a Windows library, it’s possible that an exploit would automatically work as a sandbox escape, but I haven’t seen confirmation either way. Let us know if you have some insight there.

Via Bleeping Computer

GNU Poke

The good folks at GNU have minted the 1.0 release of poke, a new binary editing tool. The real killer feature of poke is that it can interpret binary data, decoding it back into readable data structures. If you’re familiar with the way Wireshark can decode packets and give useful, organized output, it seems that poke will provide a similar function, but not limited to network traffic.

It looks like it could become a useful tool for getting a look inside otherwise opaque binaries. What poke brings is a system where you can write pretty-printing templates on the fly, which should be very useful when mapping out an unfamiliar binary. Distros will likely pick up and start packaging poke in the coming weeks, making it even easier to get and play with. Continue reading “This Week In Security: Text Rendering On Windows, GNU Poke, And Bitsquatting” →

This Week In Security: Unicode, Truecrypt, And NPM Vulnerabilities

December 20, 2019 by 22 Comments

Unicode, the wonderful extension to to ASCII that gives us gems like “✈”, “⌨”, and “☕”, has had some unexpected security ramifications. The most common problems with Unicode are visual security issues, like character confusion between letters. For example, the English “M” (U+004D) is indistinguishable from the Cyrillic “М” (U+041C). Can you tell the difference between IBM.com and IBМ.com?

This bug, discovered by [John Gracey] turns the common problem on its head. Properly referred to as a case mapping collision, it’s the story of different Unicode characters getting mapped to the same upper or lowercase equivalent.

'ß'.toLowerCase() === 'SS'.toLowerCase() // true
// Note the Turkish dotless i
'John@Gıthub.com'.toUpperCase() === 'John@Github.com'.toUpperCase()

GitHub stores all email addresses in their lowercase form. When a user sends a password reset, GitHub’s logic worked like this: Take the email address that requested a password reset, convert to lower case, and look up the account that uses the converted email address. That by itself wouldn’t be a problem, but the reset is then sent to the email address that was requested, not the one on file. In retrospect, this is an obvious flaw, but without the presence of Unicode and the possibility of a case mapping collision, would be a perfectly safe practice.

This flaw seems to have been fixed quite some time ago, but was only recently disclosed. It’s also a novel problem affecting Unicode that we haven’t covered. Interestingly, my research has turned up an almost identical problem at Spotify, back in 2013.
Continue reading “This Week In Security: Unicode, Truecrypt, And NPM Vulnerabilities” →

IP Over QR Codes

November 22, 2016 by 41 Comments

We’ve seen networks built over some interesting mediums, but QR codes has to be a new one. [Eric Seifert] decided to try to use QR codes to make an IP connection. He used these visual codes to create a bi-directional connection between two camera-equipped computers. He’s a persistent chap, because it works: in one of his videos, he shows an SSH connection between two devices.

He faced a number of challenges on the way. Although there is plenty of code to read QR codes, the data that can be encoded and read from them is limited. There is a binary mode that can be used with QR codes, but it is really inefficient. [Eric] decided to use base32 coding instead, packing the data into each frame as alphanumeric text. Each QR code image that is created and received is numbered, so the system can keep track and request any lost images. He also had some problems with keeping the data consistent between the encoded and decoded versions, so he had to add some packing to the data before it would work.  It uses Python-pytun to create a TUN/TAP device that carries the data.

The speed of the connection is rather slow: in his demo video, the two computers take over a minute to exchange keys for an SSH connection, and [Eric] measured the speed of the connection at about 100 bits per second. But even getting something like this working at all is a significant achievement. He has published his code on GitHub.

We’ve featured the work of [Eric] before: he created a data connection using an iPod FM transmitter.

Continue reading “IP Over QR Codes” →

Forgotten Internet: UUCP

January 16, 2025 by 81 Comments

What’s Forgotten Internet? It is the story of parts of the Internet — or Internet precursors — that you might have forgotten about or maybe you missed out on them. This time, we’re looking at Unix-to-Unix Copy, more commonly called UUCP. Developed in the late 1970s, UUCP was a solution for sending messages between systems that were not always connected together. It could also allow remote users to execute commands. By 1979, it was part of the 7th Edition of Unix.

Ken Thompson and Dennis Ritchie may have used UUCP on a PDP-11 like this one. (Photo via Computer History Museum/Gwen Bell)

Operation was simple. Each computer in a UUCP network had a list of neighbor systems. Don’t forget, they weren’t connected, so instead of an IP address, each system had the other’s phone number to connect to a dial up modem. You also needed a login name and password. Almost certainly, by the way, those modems operated at 300 baud or less.

If a computer could dial out, when someone wanted to send something or do a remote execution, the UUCP system would call a neighboring computer. However, some systems couldn’t dial out, so it was also possible for a neighbor to call in and poll to see if there was anything you needed to do. Files would go from one system to another using a variety of protocols.

Continue reading “Forgotten Internet: UUCP” →

Secrets Of The Old Digital Design Titans

July 18, 2024 by 46 Comments

Designing combinatorial digital circuits seems like it should be easy. After all, you can do everything you want with just AND, OR, and NOT gates. Bonus points if you have an XOR gate, but you can build everything you need for combinatorial logic with just those three components. If all you want to do is design something to turn on the light when the ignition is on AND door 1 is open OR door 2 is open, you won’t have any problems. However, for more complex scenarios, how we do things has changed several times.

In the old days, you’d just design the tubes or transistor circuits you needed to develop your logic. If you were wiring up everything by hand anyway, you might as well. But then came modules like printed circuit boards. There was a certain economy to having cards that had, say, two NOR gates on a card. Then, you needed to convert all your logic to use NOR gates (or NAND gates, if that’s what you had).

Small-scale ICs changed that. It was easy to put a mix of gates on a card, although there was still some slight advantage to having cards full of the same kind of gate. Then came logic devices, which would eventually become FPGAs. They tend to have many of one kind of “cell” with plenty of logic gates on board, but not necessarily the ones you need. However, by that time, you could just tell a computer program what you wanted, and it would do the heavy lifting. That was a luxury early designers didn’t have. Continue reading “Secrets Of The Old Digital Design Titans” →

Bypassing Bitlocker With A Logic Analzyer

August 25, 2023 by 27 Comments

Security Engineer [Guillaume Quéré] spends the day penetration testing systems for their employer and has pointed out and successfully exploited a rather obvious weakness in the BitLocker full volume encryption system, which as the linked article says, allows one to simply sniff the traffic between the discrete TPM chip and CPU via an SPI bus. The way Bitlocker works is to use a private key stored in the TPM chip to encrypt the full volume key that in turn was used to encrypt the volume data. This is all done by low-level device drivers in the Windows kernel and is transparent to the user.

TPM chip pins too small? Just find something else on the bus!

The whole point of BitLocker was to prevent access to data on the secured volume in the event of a physical device theft or loss. Simply pulling the drive and dropping it into a non-secured machine or some other adaptor would not provide any data without the key stored by the TPM. However, since that key must pass as plaintext from the TPM to the CPU during the boot sequence, [Guillaume] shows that it is quite straightforward — with very low-cost tools and free software — to simply locate and sniff out this TPM-to-CPU transaction and decode the datastream and locate the key. Using little more than a cheapo logic analyser hooked up to some conveniently large pins on a nearby flash chip (because the SCK, MISO, and MOSI pins are shared with the TPM) the simple TIS was decoded enough to lock onto the bytes of the TPM frame. This could then be decoded with a TPM stream decoder web app, courtesy of the TPM2-software community group. The command to look for is the TPM_CC.Unseal which is the request from the CPU to the TPM to send over that key we’re interested in. After that just grabbing and decoding the TPM response frame will immediately reveal the goods.

Continue reading “Bypassing Bitlocker With A Logic Analzyer” →