‹ BackHN Continuity

Thread

An agent used DNS to reach an external chatbot

198 points · 189 comments · apsec112

  1. zahlman · · focus · HN ↗
    When exactly did we forget how to make literally anything that can perform a computation but (physically, hardware-level) not have the ability connect to the Internet?

    With these companies spending the kind of money they are, if they actually mean what they say about the security risks, they should be expected to figure out those kinds of precautions and take them.

    And build Faraday cages too, just in case of a hardware supply chain compromise.

    1. 20k · · focus · HN ↗
      That's why all of this marketing about agents going rogue is so unbelievable. The only way for a tool to escape a sandbox is if you built a crappy sandbox, and after this length of time I literally don't believe that they can't do it

      This kind of sandboxing is not complex to do, especially for a company with OpenAI money. If you want your tools to explore hacking, you restrict them from internet access except for a whitelist of sites that have either opted-in, or you've very carefully vetted to make sure you won't cause any problems to. Its also not difficult to restrict their ability to make calls to be simulated, or to use fake tools that can only run the real commands if they're being run against the correct target

      This is all incredibly basic security stuff to make sure you don't accidentally cause someone problems, and I simply don't believe these AI companies anymore. Its either intentional, or gross negligence

      1. zahlman · · focus · HN ↗
        > The only way for a tool to escape a sandbox is if you built a crappy sandbox

        Well, sure, but typical software-level sandboxes are crappy at an alarmingly high rate, either on this access or the usability access. Languages like Python are fundamentally not designed for sandboxed interpretation; any Bash tool is at least as insecure as all of the vulnerabilities in all whitelisted executables.

        I'm arguing for hardware-level measures on basic defense-in-depth principles. Like, such a huge part of the reason why we're even doing this AI research is to find vulnerabilities, so it's insane to have a test environment that doesn't start from the premise that there are vulnerabilities. In everything.

        1. trollbridge · · focus · HN ↗
          Well:

          1. Park your Python or whatever code inside a VM with no connectivity to anything (other than to accept inbound ssh) and with a canned set of PyPi etc packages available for it to use

          2. Park hypervisor for that in a machine with no connectivity except thru a firewall that only admits the relevant ssh traffic.

          3. Make sure to use ssh clients that can’t be exploited by a remote server. If this is too challenging, then use telnet or rlogin instead.

          4. You can extend this to eg allow outbound calls to an LLM. Alternatively, place the GPU hardware and LLM weights inside the hypervisor machine.

          Congratulations, now nothing can escape except what you allow to from the output from rsh.

          1. zahlman · · focus · HN ↗
            Based on our existing understanding of the software, yes.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.