Date: Sun, 12 Sep 2021 14:27:16 -0700 From: Gordon Tetlow <gordon@tetlows.org> To: Karl Denninger <karl@denninger.net> Cc: freebsd-security@freebsd.org Subject: Re: Important note for future FreeBSD base system OpenSSH update Message-ID: <A8BD4882-6DCD-4A5B-BFEF-139C778FE82C@tetlows.org> In-Reply-To: <2bb56783-2727-9bea-7810-58969d91c00f@denninger.net> References: <CAPyFy2A390kS_C3g=Y9QhQcJ06z_FKUxXsNvi9g2CdWF24pukg@mail.gmail.com> <CAPyFy2B04b0GtWoHFQwxht5vK4_cnApPXpDLXU%2BRvcR=2L9YxA@mail.gmail.com> <CAPyFy2Aw8Z3ngiM8YHApjjPRLZVC5MCN8TRQkh6pj2fSeM1zqw@mail.gmail.com> <8169A4A8-B8D1-4265-87C8-74ED4D34FBC8@fasel.at> <2bb56783-2727-9bea-7810-58969d91c00f@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sep 12, 2021, at 7:40 AM, Karl Denninger <karl@denninger.net> = wrote: >=20 > I have in the field a BUNCH of "smart" rack power strips that have = this problem; their management firmware does NOT support more-modern = cipher sets and SSL requirements. I get it, those older SSL versions = are insecure and we know it. But when the browser people all decided to = kill the ability to connect to such servers with no override (that is, = don't warn, DENY with no option to get around it) all of a sudden = logging into those strips to change (for example) the name of a socket, = the alarm limits and similar became literally impossible. Contacting = the manufacturer resulted in a middle finger back; "nope, we're not = releasing new firmware for that." I've seen the same thing with some = older OOB management interfaces on server boards; they won't take an = acceptably-long (by modern standards) HTTPS server key, and thus, same = problem and same answer from the manufacturer. These are = perfectly-serviceable devices in their application and quite-expensive = to replace when there's nothing wrong with them. On the server boards by = now they've all been retired as people decided the better power budget = and performance levels made changing them (and re-purchasing the RAM = that went on them, which for larger servers is a non-trivial part of the = total expense) a reasonable proposition. This of course is not true for = a smart power strip in the rack and makes both monitoring of energy and = remote-hard-power-cycle available without a physical site visit or = remote hands. Blaming the browser and other client providers (OpenSSH, etc) for a = problem that is 100% because the devices are now abandoned by the = manufacturer is the wrong place to focus your anger. We have an enormous = problem in the industry of crappy embedded devices (like the OOB = management plane) accruing technical security debt while the = manufacturers give "a middle finger back" as you say. The supportability = of the hardware needs to be baked into the purchasing decision. = Commitments from the manufacturers on supportability timeframes are = important to understand and budget into a hardware refresh cycle. > In the case of the power strips the "answer" was one of the = prepackaged, self-contained old "portable" versions of FireFox which = complains but the alert can be clicked through. I recognize that = exposing those devices to the Internet is unsafe but have never trusted = that anyway; they're behind a gateway box with no port hole punch and if = I'm VPN'd in then it's not possible for a random person to screw with = it. >=20 > It would be sad indeed if the only answer here is "load up a partition = with an older copy of FreeBSD on some device and use that." Can we = avoid that being the answer, as it became with the browser issues? You are already accepting the risk of continuing to run devices with = known bad configurations. What's the problem with keeping that old = FreeBSD host around as well, it's just one more risk acceptance for = issues that are pretty much the same as what you are already accepting? = Alternatively, compile and install an older OpenSSH version on = well-maintained host in a dedicated prefix which is only used for that = purpose. We do need to remove the code entirely as putting it behind a = compatibility or some other "scary things are here" flag will guarantee = that manufacturers don't try to update their codebases to work with = modern protocols; they will just provide instructions on how to enable = scary mode and move on. In the interest of protecting everyone, we need = to remove this code and put it into the dustbin of history. Best, Gordon=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A8BD4882-6DCD-4A5B-BFEF-139C778FE82C>