m3047

Honey pots, tar pits, bot motels, janky configs, visible telemetry (for example): these slow down adversaries in two ways. 1) They directly slow the adversary down and force them to navigate deliberately. 2) They increase uncertainty in uncomfortable ways, the effectiveness of this depends on how important it is for the adversary to remain undiscovered, not "poke the bear". Together, the effect is more than additive.

In addition to likelihood, attacks have shape. And proper installations can force your adversaries' maneuvers to take a certain shape. I've heard this referred to as terraforming.

If you're going to "do it in the road" (a highly visible bike rack), your lock or chain works much better when it is better / stronger than the herd. If everyone has a chain which is 10x stronger, then a better grinder becomes a cost of doing business. Maybe I'd rather live in a world where I didn't use that bike rack.

It's possible to make potted meats which will store for a time at room temperature (for extra credit, ferment it like sausage) by covering them in fat. But they didn't have ceramics apparently, I don't know offhand if you could do it in something like an animal stomach. Of course, we put sausage into intestine casings... I dunno make sausages and dip them in fat?

> there has to be a name for this logical error

Are you looking for "category confusion"? It's a conflation, but let's look at the logic. (So yes, my prior is that there is logic.)

"If they generated their logo by mumbling things at a toaster / picking something from the vending machine and then 'owning' it, how likely is it that they stole a sandwich in a grubby wrapper from a bum and are going to hand it to me and say 'I made this'?"

Edit: the article is paywalled, but a number of comments remark on the owner's sense of entitlement. So my moot is probably close for throwing blind. So then that might be the real issue, and the logo is a proxy for a perception of lack of work + mental bullying.

> The disclosure even says the concern for single user systems is very low.

For single user systems (not rigorously defined, I presume it's the intersection of our two definitions which we might be talking about) the nature of the exploit is local privilege escalation, of which there could be many possible, and many mitigations / countermeasures against. This could have suddenly appeared from the ether of "unknown unknowns" for some people.

Those people farther up the food chain still potentially have service accounts, maybe even user accounts for some purposes, perhaps "trusted" services which deliver them code which they deserialize and run once. (Have a pickle.)

severity * impact * likelihood

Not everyone looking to migrate from Windows 95 plans to run everything as root afterward.

On the copy.fail site:

    echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
    rmmod algif_aead 2>/dev/null || true

Not everybody needs or wants to wait for their distro, or plans to patch their IC firmware when a config change will do.

I hope when people see RCS rev data on some of the stuff I publish it gives them pause.

This just in, licorice kills dogs. Once in a while it kills people too. (affects insulin production, and aldosterone causing blood pressure effects then downstream effects on blood potassium and kidneys)

It's an audio processing chip, so probably not going to show up in a charging cable. Although the engineering part of my brain says "noise" shows up in a lot of places...

I wasn't thinking specifically of the speed of light, what other "significant" numbers are there and what "significant" physical artifacts correspond to them? I would expect the definition of "significant" is going to play a big part in it. In the back of my mind, some things I'm observing in how people explain what AI does make me feel like they're relying on normal distributions to carry a lot of water. If something is an "outlier / coincidence": is it? What distribution(s) does it belong to? Just a nagging feeling at this point.

"Of course it's a coincidence" doesn't leave me with good feels. See, we don't know what a "normal distribution" is for a correlation like this, it's not like we have a huge bag of samples to determine the variance from.

nc /s

It some cases it was possible for the server to use escape sequences to "read back" parts of what the terminal displayed.

Architecture Astronaut! TCP is a stream protocol. A terminal program is expected to honor the stream protocol: I can use a terminal program to speak SMTP or HTTP. I can paste binary shit into it and copy binary shit out of it (some caveats apply).

If you're gonna jack some control protocol into a session which is sitting directly on the stream protocol, that's on you. This is as airtight as injecting a control protocol into SMTP or HTTP. Encapsulate the entire protocol (obviously this requires presence on both ends), open a second channel (same), or go home. It's worth noting that the "protocol" drops a helper script on the other side; so theoretically it is possible for them to achieve encapsulation, but doing it properly might require additional permissions / access.

Obviously they published a fix, since that's how the exploit was reverse engineered. This is "...what happens when terminal output is able to impersonate one side of that feature's protocol."

Amtrak sucks in so many ways, but that said for almost a decade prior to COVID when I had the opportunity (roughly yearly) I'd travel Amtrak first class between Tacoma WA and Oakland CA (Starlight). Kind of a day's vacation going each way (and they'd sell you a tax free bottle of good wine you could wander around first class with).

It was weird, I would arrive in Oak / SF rested, grounded, not nearly as stressed... and without a flying horror story to share (although the "alien abduction" made a good story). [0]

At the end of the journey Amtrak sucked, but flying sucks more; so much of the suck is fixable in both cases but it never seems to happen.

[0] I'd rate your chances as about 1:3 something unexpected will occur. An 11PM electrical fire / "alien abduction". They put the train together wrong / in a hurry and first class was right behind the engines (they sealed the door with duct tape to keep the rain / snow / wind out), and at night going through the Cascades in OR there were a half dozen of us crowding around with our wine bottles looking out over the engines; very cool. A freight broke apart in the Cascades stretch and we sat in the bar car (drinking wine) and watched the maintenance crews humping connector knuckles from behind us up to the freight in front of us (some of those freights are over a mile long; did I mention we were basically on the side of a cliff?).

Includes numerous JVM implementations, including Azul Systems'.

> They'd just type tens of invalid commands, get frustrated and quit.

Is that like the "players" who send HTTP requests to my mail server?

Methane (natural gas) is lighter than air. Give it a go. Don't get any oxy contaminating it though.

TIL: it is 09 Apr somewhere in the world for 50 hours.

1) Surveillance needs to be reviewed. Even if reviewed by AI, eventually that reviewed work needs to be reviewed by a human if we're going to maintain the fiction / friction of "human in the loop". The "hits" will include false positives, unless the system is overtuned so that it rarely kicks an event.

1a) Review will take time / resources which could be spent on human policing, harming the community.

1b) Some jurisdictions may prefer "broken windows as policy", the notion that they can construct a "reasonable suspicion", given enough garbage (some of it outright garbage, the point being there is so much of it nobody cares; don't need to do an accurate drug test until trial, right?).

2) False surveillance hits will make it through human review and result in injury to innocent humans.

3) Police forces already lack the money / manpower to investigate potential crimes.

4) Police forces already "prioritize" other matters than the mentally ill setting their houses on fire or releasing plagues of rabbits into their neighborhoods (actual things that have happened to me!).

See also sibling comment, the Big Three offer free annual credit reports through https://www.annualcreditreport.com/index.action but I haven't seen work history included. I believe that they do collect & report on this information, but I have been unable to get them to share it with me.

Dunno, kind of sounds like hiring and then negotiating compensation.

Microsoft beleaguered a federal agency which pretends to be a lot larger than it is (and has a lot of help doing it) with nonresponsive filings. The employees of that agency, FedRAMP, referred to Azure as "a pile of shit" but ultimately approved it anyway.

   https://www.propublica.org/article/microsoft-cloud-fedramp-cybersecurity-government

It's hard to find hard numbers (I looked), but in the "FedRAMP over 10 years" chart partway down in this article FedRAMP themselves claims to have approximately 25 employees, which (I infer prior to DOGE) was augmented to approximately 80 staff with contractors.

   https://www.fedramp.gov/2025-09-30-fedramp-built-a-modern-foundation-in-fy25-to-deliver-massive-improvements-in-fy26/

I swear that once upon a time I sat at a desk, and it had a label printer sitting on it, and the box of labels was in a box fed through a hole pretty much like that... except I think it was kinda square with rounded corners. The "shelf" under the main part looks like you could put a retractable keyboard mount under there. Is this a joke?

Let me address a sibling comment first:

stub resolver (client) -> OPTIONAL forwarding resolver (server) -> recursing / caching resolver (server) -> authoritative server. "Personal DNS server" doesn't disambiguate whether your objective is recursive or authoritative... or both (there is dogma about not using the same server for both auth and recursion, if you're not running your resource as a public benefit you can mostly ignore it). If it's recursive I don't know why you'd run it in the cloud and not on-prem.

You'll find that you can restrict clients based on IP address, and you can configure what interfaces / addresses the server listens on. The traditional auth / nonrepudiation mechanism is TSIG, a shared secret. Traditionally utilized for zone transfers, but it can be utilized for any DNS request.

The traditional mechanism for encryption has been tunnels (VPNs) but now we have DoH (web-based DNS requests) and DoT (literally putting nginx in front of the server as a TCP connection terminator if it's not built in). These technologies are intended to protect traffic between the client and the recursing resolver. Encryption between recursing resolvers and auths is a work in progress. DNSSEC will protect the integrity of DNS traffic between recursives and auths. I don't know how big your personal network is, for privacy / anonymity of the herd you might want to forward your local recursing resolver's traffic to a cloud-based server and co-mingle it with some additional traffic; check the servers' documentation to see if you can protect that forwarder -> recursive traffic with DoT or you're not gaining any additional privacy; it's extra credit and mostly voodoo if you don't know what you're doing. I don't bother, I let my on prem recursives reach out directly to the auths. Once the DNS traffic leaves my ISP it's all going in different directions, or at least it should be notwithstanding the pervasive centralization of what passes for the federated / distributed internet at present.

Yes, you can have a different root zone which includes some or all of ICANN's root servers, or none of them. However if the root zone doesn't match ICANN's then DNSSEC will fail ("fruit of the poisoned tree"). But you could sign your alternate, custom root, and issue DNSSEC keys all the way down.

You don't need ICANN for TLS or encryption. You can create your own CA and sign your own certs. In fact, this is typically how it's done to authenticate for example clients of a web server using certs (you install the cert in the browser).

You can use your CA to sign a cert for your ICANN-registered domain and install it in the web server; there are no internet police who are gonna stop you. Web browsers will complain about this "self-signed cert", unless you install your CA's public key in your browser. (Security-wise, you probably shouldn't go around installing random people's CA certs in your browser. You need to trust them not to issue certs for e.g. google.com. On the other hand you need to trust China and Morocco not to do that already, so maybe you're willing to accept that risk.)

> Is obtaining a domain name registration from an "ICANN-approved" registrar proof of identity for purposes of "authentication".

People make the mistake of conflating an FQDN or address with identity all the time. People point at resources in domains which don't exist (this includes DNS resources), and people register those abandoned domains and then click "forgot password" and take over whatever account was tied to that email address in that domain.

I don't know that ICANN requires any proof. There are CAs which have enhanced identity verification, this applies to the certs they issue for both servers and clients / people.

> What purpose does _purchasing_ a registration serve.

Makes you a member of ICANN's club. There are pseudo-TLDs which are registered in ICANN's tree where you can register a (sub)domain, without interacting with ICANN at all.

Rhetorically speaking, of course.

Compared to hardening your network, at least visiting the ZT church once in a while, running your router on a box which You control and which implements proper segmentation, provides DNS (and "DNS firewall") and an adaptive firewall, WAF (if you run web services), isolating your wifi (anything EXCEPT running it in the box provided by the ISP)?

No.

And you have to accept living with / mitigating that e.g. that isolated wifi access point theoretically receives and will need to apply software updates. /s People seem to treat it as some kind of heresy if you simply deny such appliances internet access.

One dog's exploit is another's Clippy. I've certainly seen companies downgrade security generally when they deploy (and enable by default) new features. Start with web browsers. Ads in software you paid for. Always on app telemetry. Cloud backups. Cloud-compute assisted "desktop" tools. Sorry, out of time.

> Buying or selling tools designed to break the law is already illegal - trivial or not.

I'm curious how this will play out. The "John Deer" exemption from the DMCA comes to mind, not sure if it's strictly for farm equipment or still in effect.

If you're selling ammonium nitrate and diesel, it's a reasonable presumption that you're in the agricultural supply business. It's also reasonable to expect you not to sell a truckload of both to someone who you don't know to be a farmer.

I'll tell you what I expect to see from crawlers, agents and which I'm enforcing on everybody who doesn't look distinctly human:

* Reverse DNS which points to a web site which has a discoverable / well-known page which clearly describes their behavior.

* Some sort of reverse IP based, RBL and SPF -inspired TXT records which describe who, what, when, why, how, how often

so that I can make automated decisions based on it.

Yah, I don't have a lot of crawlers that I welcome... but I'm building a pretty good database of the worst offenders. At scale... there are advantages to scale which work in my favor, actually.

I documented this at the end of a blog post when I made blocking Amazon incoming requests a default policy several years ago.

Seems like it was just hours ago they started reaching out to my edge servers from their address space (Me: why is a reverse proxy service banging my servers when I'm not a customer? did some miscreant sign me up somehow?) and it was for Apple, privacy, mom and pie (a VPN service, dressed in noble aspirations). It never quite smelled like pie to me.

If you're doing threat hunting / risk enumeration, Cloudflare is no longer a passive service that miscreants hide behind, they now actively reach out and grab your privates.