DominoTree

It seems like every day there's some new "expose your laptop to the internet!!!111" service (or protocol or methodology) that I have to block or otherwise disable at work.

Users and their agents are constantly trying to make all sorts of horrible things forward-facing, and what sucks is that there's not a comprehensive way to block this stuff categorically without severely impacting a ton of legitimate usage.

(And yes, we have _very_ easy sanctioned ways for users to deploy things onto actual managed hosts and make them forward-facing)

I was looking earlier and the majority of these do not have a CVSS score assigned to them yet, but a lot of them that did were >7.0 (although I suppose by nature that the more impactful CVEs are going to be scored more quickly)

> This allowed devices to evade monitoring, transmit untracked data outside secure channels, and potentially enable leaks or hacks

Pretty sure that was the point

JPEG 15 Pro Max

## Recommendation

Do not run a telnetd server at all.

For a window of a few minutes until the key gets automatically revoked

Assuming that they took any of your files to begin with and you didn't discover the hidden prompt

I still don't have IPv6 at home in the middle of San Francisco with Google Fiber / Webpass and have to egress through an HE.net tunnel like it's 2002 again

Trusting an AI to write an RBAC system feels like asking for trouble

Traditionally I've seen these adapters primarily used to pass binaries for other architectures to QEMU and similar.

Years ago on FreeBSD I created a "Volkswagen mode" by using the similar `imgact_binmisc` kernel module to register a handler for binaries with the system's native ELF headers. It took a bit of hacking to make it all work with the native architecture, but when it was done, the handler would simply execute the binary, drop its return code, and return 0 instead - effectively making the system think that every command was "successful"

The system failed to boot when I finally got it all working (which was expected) but it was a fun adventure to do something so pointless and silly.

It would be a similarly clever place to maintain persistence and transparently inject bytecode or do other rude things on FreeBSD as well

I have a GitHub action that uses an OAuth token to provision a new key and store it in our secrets manager as part of the workflow that provisions systems - the new systems then pull the ephemeral key to onboard themselves as they come up

It can get especially interesting when you do things like have your GitHub runners onboard themselves to Tailscale - at that point you can pretty much fully-provision isolated systems directly from GitHub Actions if you want