Kula; Certifiable SSH; From cat to Calculator.app

Onboarding at Censys was a firehose this week and the norovirus is still managing to make the days pretty tiring. But, I said the Drops are back, so we can ease into the full release schedule with some Bonus ones.

Today’s Drop has a cybersecurity throughline, since that underpins the resources each section.

---

Kula

Most server monitoring tools treat security as an afterthought. To be clear, they do need broad read access to work, so they generally get broad read access, and that’s usually the end of the convo. Kula (GH), a single-binary Linux monitoring tool from c0m4r, takes the opposite position: it uses Landlock (full ABI v4, Linux 6.7+) to sandbox itself at the kernel level, with read-only access on /proc and /sys, read-only on its config file, and read-write only on its own data directory. The network binding is restricted to a single TCP port. This ends up creating a meaningfully constrained attack surface for a daemon that runs continuously with access to your system metrics.

The rest of the security stack is similarly deliberate. The web layer ships with strict Content-Security-Policy headers and per-file nonces on every JS asset, plus Subresource Integrity checksums on all dashboard scripts to catch tampering. Authentication, if you enable it, uses Argon2id with tunable parameters. Rate limiting is built in for API endpoints. The project docs also walk through stateful egress filtering via iptables/nftables to block all outbound connections from the Kula user account. This is some spiffy supply chain mitigation I’d normally expect to see at a much larger [commercial] project. There are zero outbound connections by design: no telemetry, no update checks, no external APIs. It runs on closed and air-gapped networks without modification.

The actual monitoring engine is worth taking some time to grok. The binary reads /proc/stat, /proc/meminfo, /proc/diskstats, /proc/net/*, and the rest of the procfs/sysfs surface every second, building a Sample struct that covers per-core CPU with steal and guest time, memory including dirty/mapped/shmem, per-interface network with TCP/UDP/ICMP breakdown, per-device disk I/O with filesystem and inode usage, thermal sensors, process state counts, and entropy. Storage is a three-tier ring-buffer engine in pre-allocated binary files: 1-second raws (~250MB), 1-minute aggregates (~150MB), 5-minute aggregates (~50MB). Disk usage is bounded and nothing needs cleanup. The Chart.js dashboard SPA – with SVG gauges, interactive zoom, dark/light themes – is embedded in the binary via Go’s embed. The whole thing is about 8MB, built CGO_ENABLED=0. (There’s also a TUI mode via bubbletea/lipgloss if you’d rather stay in the terminal.)

I’ve started running it on an arm64 Hetzner box behind Tailscale. The binary “just works”. Since I know some folks care about such things, c0m4r notes heavy LLM use in development alongside regular security-focused code reviews; the Landlock and CSP/SRI implementations are both done correctly, which is evidence enough for me. The project is at v0.14.0 with 30 releases since late February, which is pretty healthy velocity for a solo maintainer.

Explicit tradeoffs are right there on the tin: no Prometheus export core, no alerting pipeline, no multi-host aggregation, Linux-only by design. This is where you go when you need 1-second resolution monitoring running on a box in under a minute, without touching a database or a config management system. Def note the AGPL license (so, internal use is fine).

This one’s a keeper.

---

Certifiable SSH

Jan-Piet Mens always does a phenom job explaining technical concepts, so this section just gives you a taste of what’s in store so you’ll hopefully read “SSH certificates: the better SSH experience” (in fact, please feel free to stop reading and just head there!).

Most of us have muscle memory for typing “yes” at that SSH host key prompt. We don’t verify the fingerprint. We don’t call the server admin. We just accept it and move on. “Trust on First Use” (TOFU) sounds like a security model; in practice it’s a hope-based model.

The same pattern plays out with key management. Public keys accumulate in authorized_keys files across dozens of machines, nobody remembers which ones are still needed, and deprovisioning a user means hunting through every server they ever touched. It works fine until it doesn’t, and “until it doesn’t” usually means an incident.

SSH certificates fix all of this, and they’ve been available in OpenSSH since 2010 (so, over fifteen years). The tooling is the same ssh-keygen you already know. No X.509 complexity, no external dependencies, no new daemons. You create a CA key pair, sign host and user keys with it, and the entire TOFU problem disappears. User access gets time-bounded, principal-scoped, and source-address-restricted — all embedded in the certificate itself, not scattered across authorized_keys files on target hosts.

JP works through the full setup with real shell sessions: creating the CA, signing host and user keys, configuring sshd, handling revocation, and even automating host key certificate distribution with a small HTTP signing service. If you manage more than a handful of servers, set aside ~twenty minutes and read through it.

---

From cat to Calculator.app

Calif (a security firm from California) found a “fun” bug in iTerm2 (GH) where something as innocent as cat readme.txt led to arbitrary code execution. NOTE: If you’re not on macOS, skim it anyway, because the vulnerability class (terminal emulators trusting their output stream as a command channel) has a long history on Linux and Windows and it’s currently getting a fresh round of scrutiny from automated tooling.

Read-only operations have always been a mental safe harbor. You’re not running code, not piping output to a shell, not doing anything that should have side effects. This iTerm2 bug erases that intuition. The attack is protocol impersonation: iTerm2’s SSH integration communicates with its remote conductor script over the same PTY that carries normal terminal output, using DCS 2000p sequences to establish a conductor session and OSC 135 messages for command traffic. Nothing validates that those sequences come from an actual SSH session. A crafted file gets processed identically to a legitimate conductor.

The mechanics are scarily straightforward. The malicious file forges a DCS 2000p hook carrying an attacker-chosen sshargs value, then supplies fake OSC 135 responses to the getshell and pythonversion queries that Conductor.start() issues automatically. Returning failure on pythonversion is deliberate – it nudges iTerm2 into a fallback that constructs a run(...) command, base64-encodes it, and writes the result to the PTY. The sshargs value was pre-selected to ensure the final 128-byte base64 chunk decodes to ace/c+aliFIo, a relative path to an attacker-placed executable. The earlier chunks generate shell garbage that dies quietly. That last one doesn’t.

The thing that makes this more than a one-off quirky bug report: it was found by OpenAI Codex as part of Calif’s MAD Bugs project, and there are more where it came from. An LLM agent found a multi-step protocol impersonation vulnerability requiring precise byte-level payload alignment. That’s a meaningful data point about what automated agents are capable of when pointed at a codebase – and the capability is symmetric. The same agents security researchers are using to clear backlogs of subtle, hard-to-find bugs are available to anyone else with a credit card and a target.

Terminal emulator trust boundary bugs have accumulated quietly for years because they require the right combination of protocol familiarity and adversarial curiosity to surface. Agents supply both, at scale, without getting distracted. The rate at which these get found – and raced to patch or exploit – is going to increase. Whether the researchers or the adversaries win more of those races depends partly on how seriously the tooling community takes the signal from bugs like this one before the noisier incidents start happening. Update iTerm2. And maybe think twice about cat-ing files from repos you don’t control until the terminal emulator world has had a few more uncomfortable months.

---

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on:

• 🐘 Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev
• 🦋 Bluesky via https://bsky.app/profile/dailydrop.hrbrmstr.dev.web.brid.gy

☮️