Maybe you shouldn't install new software for a bit

Original Article ↗ Hacker News Discussion ↗

Kernel LPEs, disclosure, and immediate risk

  • Thread revolves around recent Linux local-privilege-escalation bugs (Copy Fail / Dirty Frag / variants).
  • Confusion over disclosure: some think embargo was broken; links show third parties derived exploits from public patches.
  • Debate on responsible disclosure: seen as a “gentleman’s agreement” under strain from low bounties and AI‑generated low‑quality reports.
  • Several note that if fixes are public, LLMs can help reverse patches and generate exploits faster.

“Don’t install new software” and supply-chain attacks

  • OP’s advice is read as: short, one‑time moratorium on installing new software while kernel vulns are unpatched, especially via npm.
  • Rationale: a compromised npm package could chain the LPE to get root on many systems (dev machines, CI, servers).
  • Some call this FUD or “attacker logic” (“don’t update your systems”), arguing unpatched old software is a bigger risk.
  • Others think the advice is narrowly reasonable for this particular week, not as a general practice.

Dependency management & cooldowns

  • Strong concern about npm/PyPI/Cargo attacks via account compromise and malicious releases.
  • Proposed mitigations:
    • “Cooldowns”: only allow package versions older than X days; let others be the beta testers.
    • Corporate artifact repositories / allow‑lists (e.g. artifact managers, internal mirrors).
    • Pin exact versions and use lockfiles correctly (npm ci, --frozen-lockfile).
    • PR guards that forbid unpinned or lockfile‑mismatched deps.
  • Critiques:
    • Cooldowns can delay real security fixes.
    • Attackers can just wait out the cooldown or label malware as “security updates.”
    • Reviewing all transitive deps is often infeasible; many “curated” repos mostly bump versions and hashes.

OS choices and security postures

  • Some advocate BSDs (especially FreeBSD, OpenBSD) for more coordinated security handling and faster binary updates.
  • Pushback notes gaps like late ASLR adoption, missing kASLR, past incidents (e.g., buggy WireGuard import), and weak defaults.
  • Microkernels and capability systems (e.g., seL4) discussed as structurally safer, but others argue they don’t inherently stop logic bugs in critical components like filesystems.

Sandboxing, containers, and practices

  • Many recommend isolating risky tooling (npm, pip, gem, etc.) in containers/VMs; avoid installing such tools on the host.
  • Examples: Docker, Kata, Qubes OS, macOS firewalls (e.g., LuLu), disabling kernel modules (esp4/esp6/rxrpc) as temporary mitigations.
  • Consensus that user‑space compromise plus easy sudo use is already near‑“game over”; proper isolation and minimal privileges matter more.

Broader reflections

  • Widespread sense that:
    • Package ecosystems and “curl | sh” norms have created enormous attack surfaces.
    • AI accelerates both vulnerability discovery and “slopcode” generation.
    • Open source’s economic model (heavy corporate dependence, light maintainer support) is under serious strain.