0

The image loaded with docker load will be user submitted, and I may also add additional files to it (which could also be potentially malicious). A container will then be created based on the image, and run with runsc (gVisor) runtime.

In my application, I plan to have users first submit archives generated by running docker save (in their local machine) to my server which are immediately written to a storage service like S3.The archive is later downloaded locally into one of my VMs with docker and gVisor installed.

This VM must have a workflow written in Go that first runs cli.ImageLoad (cli is of type client.Client in docker's Go SDK) to load the image into the local image cache.

After loading, a container is created using cli.CreateContainer method. At this point I should make sure the Runtime runsc is set when passing the HostConfig config to this method.

After that, some files are copied into the container (both the image and these files could potentially be malicious) by running cli.CopyToContainer.

Once these steps are completed, the workflow will just start the container by running cli.ContainerStart.

Also, I may additionally use methods like cli.ContainerCommit if needed.

Is there anything wrong with this design security vice, assuming I implement this correctly? Is it safe to use these methods when dealing with potentially malicious image and code?

1 Answer 1

1

Well, lets check what does docker load do:

Load an image or repository from a tar archive (even if compressed with gzip, bzip2, or xz) from a file or STDIN. It restores both images and tags.

what does this mean:

  • Docker is decompressing the file, meaning any and all attacks related to decompressing are at play.
  • docker is interpreting some of the contents of the file, specifically the meta data. any attack that abuses this vector is at play.

now to address your question, "is it safe to run docker load on a potentially malicious archive", the answer is: "Probably not", especially if you are getting attacked by files with attacks that specifically target dockers load functionality. but whether its more than probable depends on your threat model.

3
  • That makes sense. But I don't really know if there is a way to start a container without first loading the image to the local cache using ImageLoad using the docker API. Another way to do this will be to run runsc command directly. But I don't know much about containers to make that happen. It would be great if Docker validates its metadata extensively.
    – Sreram
    Aug 23, 2023 at 15:56
  • 1
    That’s why we make threat models. To see what risks are ok enough to live with. And you could employ “scanning machines” that try and figure out of the image itself has been tainted, by using not docker but just archive unpackers and other scanning tools.
    – LvB
    Aug 24, 2023 at 7:19
  • For now, I plan to scan and validate the metadata of images, before calling any operations on it. Thankfully, all their metadata are in JSON, and quite easy to understand as well. If the binaries contain something malicious, then it might still not be a problem as gVisor will likely prevent it from breaking out of the container.
    – Sreram
    Aug 24, 2023 at 18:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .