4 ms·

> systemd-resolved could be made to crash or run programs if it received a specially crafted DNS response. As nation states are hording zero days, and the secu

by 5ilv3r 9y ago

> systemd-resolved could be made to crash or run programs if it received a specially crafted DNS response. As nation states are hording zero days, and the security sheep herd insists updates are the way to go, I have never been more convinced that sticking to an OLD AND TRUSTED source code base for your infrastructure is the way to go. You can pop layers on top of that to get newer software running if you like, but trying to keep up with this psuedo-rolling-release avalanche of crap coming down the pipe is not a fair burden for administrators to handle. The devs need to shove it because we don't want it. I am hoping the next economic recession starves out the enthusiasm for disposable infrastructure and "move fast and break things" and businesses can go back to focusing on long term stability.

rsync 9y ago
"I have never been more convinced that sticking to an OLD AND TRUSTED source code base for your infrastructure is the way to go." I recently (2016) built a little network appliance for a specific task that needed to be safe and secure. I used FreeBSD 4.11.
- qb45 9y ago
  Are you sure it has no remote vulns since it's been discontinued or did I just prove Poe's law?
  - wahern 9y ago
    I think that's called security by obsolescence. Not sure how well that actually works. Root kits don't just disappear and FreeBSD 4.1 isn't as obscure as, say, VMS. But as long as there are no remote vulnerabilities it's probably no worse than a typical Linux install, in the sense that both would be trivially rootable once you get your foot in the door.
    - 5ilv3r 9y ago
      Usually with BSD you can apply new patches to old systems without any trouble. No need to upgrade everything.
      - wahern 9y ago
        Maybe FreeBSD is different, but I've run OpenBSD for 17 years and this is definitely not the case for all BSDs. Because OpenBSD is a cohesive system they're not afraid to do aggressive refactors. Which means subsystems can change drastically within just a few release cycles, meaning you can quickly lose the benefit of further fixes. For example, just today Theo announced that he's staging the removal of TIOCSTI, the perilous ioctl that allows injecting data into a process group TTY. It's a huge break with historical BSD. That means if there's a TIOCSTI exploit found next year (say, in the NetBSD or FreeBSD code) that effects OpenBSD 6.0, there won't be an OpenBSD fix to backport; you'll have to craft one yourself and maintain it going forward. NetBSD imported Lua 5.1 (IIRC, or maybe Lua 5.2) into their base, then in later releases upgraded it to Lua 5.3. the difference between Lua 5.1 and Lua 5.3 is like the difference between Python 2 and 3. Plus, Lua 5.1 is completely unmaintained at this point. If you're on an unsupported NetBSD release don't expect any fixes coming down the pipe for Lua 5.1. But I admit that FreeBSD is definitely not OpenBSD, for better and worse, in terms of the pace of major refactoring work.

by 5ilv3r 9y ago

rsync 9y ago

"I have never been more convinced that sticking to an OLD AND TRUSTED source code base for your infrastructure is the way to go." I recently (2016) built a little network appliance for a specific task that needed to be safe and secure. I used FreeBSD 4.11.

qb45 9y ago
Are you sure it has no remote vulns since it's been discontinued or did I just prove Poe's law?
- wahern 9y ago
  I think that's called security by obsolescence. Not sure how well that actually works. Root kits don't just disappear and FreeBSD 4.1 isn't as obscure as, say, VMS. But as long as there are no remote vulnerabilities it's probably no worse than a typical Linux install, in the sense that both would be trivially rootable once you get your foot in the door.
  - 5ilv3r 9y ago
    Usually with BSD you can apply new patches to old systems without any trouble. No need to upgrade everything.
    - wahern 9y ago
      Maybe FreeBSD is different, but I've run OpenBSD for 17 years and this is definitely not the case for all BSDs. Because OpenBSD is a cohesive system they're not afraid to do aggressive refactors. Which means subsystems can change drastically within just a few release cycles, meaning you can quickly lose the benefit of further fixes. For example, just today Theo announced that he's staging the removal of TIOCSTI, the perilous ioctl that allows injecting data into a process group TTY. It's a huge break with historical BSD. That means if there's a TIOCSTI exploit found next year (say, in the NetBSD or FreeBSD code) that effects OpenBSD 6.0, there won't be an OpenBSD fix to backport; you'll have to craft one yourself and maintain it going forward. NetBSD imported Lua 5.1 (IIRC, or maybe Lua 5.2) into their base, then in later releases upgraded it to Lua 5.3. the difference between Lua 5.1 and Lua 5.3 is like the difference between Python 2 and 3. Plus, Lua 5.1 is completely unmaintained at this point. If you're on an unsupported NetBSD release don't expect any fixes coming down the pipe for Lua 5.1. But I admit that FreeBSD is definitely not OpenBSD, for better and worse, in terms of the pace of major refactoring work.