• flashgnash@lemm.ee
    link
    fedilink
    arrow-up
    7
    ·
    edit-2
    9 months ago

    You would think you’d already have problems if someone’s managed to compromise one or more of your containers without you knowing though whether they can get the host or not

    Could be serving users malware or silently sucking up all the sensitive data the container sees

    What if anything do people do about anti virus in containers?

    • 520@kbin.social
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      9 months ago

      You would think you’d already have problems if someone’s managed to compromise one or more of your containers without you knowing though whether they can get the host or not

      True, but the security idea behind being in a containerised environment is that your problems aren’t immediately made worse by the fact that your database server is on the same machine as your web application - since they’d both be on separate but networked containers.

      What if anything do people do about anti virus in containers?

      The real threat to containers isn’t AV-detectable malware, but Remote Code Execution (RCE) exploits.

      Containers are best used as single purpose installations. With that configuration, it isn’t easy to get non-standard executables - including malware - onto a container.

      Most RCE exploits also don’t involve the dropping of malware files onto the file system. There are some that do, but that issue is better handled in other ways.

      Why? Well AVs only do something about binaries they know or think to be malware. A well crafted, customised Cobalt Strike beacon (aka: malicious remote control software) will blow through any resistance an AV has to offer.

      So what do we do? Remember what I said that containers are best used as single purpose installations? Therefore you know exactly what executables should be running, making it trivial to set up executable whitelisting. That means that any executable not on the list will not run.

      But even that isn’t completely bulletproof. It won’t do much against web shells, in which case your best detection mechanism is to look for applications calling /bin/bash or /bin/sh that shouldn’t be.

  • jbk@discuss.tchncs.de
    link
    fedilink
    arrow-up
    5
    ·
    9 months ago

    Wouldn’t rootless containers have reduced the impact of these vulnerabilities? I’ll happily continue using rootless podman for simple tasks

  • Goku@lemmy.world
    link
    fedilink
    arrow-up
    2
    arrow-down
    1
    ·
    9 months ago

    Dang that’s scary. The user would need ssh access to the container for this to work, right?

    • chameleon@kbin.social
      link
      fedilink
      arrow-up
      10
      ·
      9 months ago

      Even worse than that, they need to be able to make an arbitrary container from an arbitrary attacker-provided Dockerfile, or make fairly arbitrary calls to the Docker daemon (in which case you’ve already lost).

      They’re rather uninteresting for anyone self-hosting containers as the runc vuln doesn’t offer a way to escape from within an already running container, while the BuildKit vulns all have fairly odd preconditions or require passing untrusted input. Quite the annoyance if you’re running some kind of public cloud or public CI/CD service, though.