Brief items

About a month ago we presented honware at eCrime 2019; [it is] a new honeypot framework that enables the rapid construction of honeypots for a wide range of CPE and IoT devices. The framework automatically processes a standard firmware image (as is commonly provided for updates) and runs the system with a special pre-built Linux kernel without needing custom hardware. It then logs attacker traffic and records which of their actions led to a compromise.

We provide an extensive evaluation and show that our framework is scalable and significantly better than existing emulation strategies in emulating the devices’ firmware applications. We were able to successfully process close to 2000 firmware images across a dozen brands (TP-Link, Netgear, D-Link…) and run them as honeypots. Also, as we use the original firmware images, the honeypots are not susceptible to fingerprinting attacks based on protocol deviations or self-revealing properties [PDF].

In light of recently-published chosen-prefix attacks on SHA1 [1], I caution that it is no longer safe to use Epiphany, or any other WebKitGTK-based browser, or libsoup, or any applications based on libsoup, or any other applications using GLib's networking facilities, in combination with GnuTLS versions older than GnuTLS 3.6. GnuTLS versions prior to 3.6 will accept certificates that use SHA1 signatures. It is now both possible and economically-feasible to forge these signatures. Your secure connections can no longer be trusted to be secure when using these older versions of GnuTLS.

It's a long (32 pages) but interesting read. The only thing I have a bit of an issue with is the conclusion:

SHA-1 signatures now offers virtually no security in practice

It should really be "SHA-1 signatures where the attacker has two months time and tens of thousands of dollars (there are some cheaper options than $75k) to prepare a forgery offer no security in practice".

Even then, the demonstrated attack relies on the ability to stuff arbitrary garbage data into the signed message (in this case into a JPEG image after the End-of-Image marker), so add:

"... and the ability to stuff arbitrary attacker-chosen data into the signed message..."

to that.

So you might want to look into not the standard library implementation, but specific locking implementations for your particular needs. Which is admittedly very very annoying indeed. But don't write your own. Find somebody else that wrote one, and spent the decades actually tuning it and making it work.

Because you should never ever think that you're clever enough to write your own locking routines.. Because the likelihood is that you aren't (and by that "you" I very much include myself - we've tweaked all the in-kernel locking over decades, and gone through the simple test-and-set to ticket locks to cacheline-efficient queuing locks, and even people who know what they are doing tend to get it wrong several times).

In the end, enterprise software upgrades at the rate of whatever the majority of accounting systems need to make payroll and tax filings happen.

Why do I care so much about unexpected stacktraces? I do because mat2 is dealing with untrusted fileformats: users will throw all kind of random malformed files at it, and I'm expecting meaningful exceptions that I can catch should something go wrong, not eldrich-like unpredictable monstrosities crawling from the depth of Python's core in a fireworks of traces scaring my beloved users away.

And hidden therein is my actual point: complexity. There has long been a trend in computing of endlessly piling on the abstractions, with no regard for the consequences. The web is an ever growing mess of complexity, with larger and larger blobs of inscrutable JavaScript being shoved down pipes with no regard for the pipe’s size or the bridge toll charged by the end-user’s telecom. Electron apps are so far removed from hardware that their jarring non-native UIs can take seconds to respond and eat up the better part of your RAM to merely show a text editor or chat application. [...]

I use syscalls as an approximation of this complexity. Even for one of the simplest possible programs, there is a huge amount of abstraction and complexity that comes with many approaches to its implementation. If I just print “hello world” in Python, users are going to bring along almost a million lines of code to run it, the fraction of which isn’t dead code is basically a rounding error. This isn’t always a bad thing, but it often is and no one is thinking about it.