1

Scenario:

  • There are two computers running GNU/Linux, U and T.
  • U is untrusted and T is trusted.
  • A non-executable file F (which may however have been infected with malware) resides on U. (For instance, an H.264 video file in a .mov wrapper.)
  • It is needed to copy that file to T and to view that file on T, with minimal risk of compromising T.
  • The human operator has both root and physical access to U and T.
  • U and T can optionally be connected by LAN.
  • U and T both have USB sockets and SD-card slots. A USB stick and an SD card, each large enough to contain F, is available.
  • No proprietary software can be used.

There are various possible methods for copying the file from U to T and viewing it on T. Here are two examples:

  • Update ClamAV on T. Use firewall on T to disallow all incoming connections. Connect U and T via LAN. Initiate an SCP command from T to U to retrieve a copy of F. Scan F with ClamAV on T and modify F if necessary (e.g. disinfect). View F on T with most well-audited software available (e.g. in case of video files I guess this might be mplayer or VLC or suchlike).
  • Update ClamAV on T. Copy F from U to USB stick or SD-card and from there to T. Scan F with ClamAV on T and modify F if necessary (e.g. disinfect). View F on T with most well-audited software available.

You may be able to think of other methods.

Of the various possible methods for copying the file from U to T and viewing it on T, which has the lowest risk of compromising T, and why?

  • If this really matters, I would go with a 3rd computer "sandbox" and run the file there before risking either U or T – Carl Witthoft Dec 24 '13 at 0:42
  • I was curious whether anyone would suggest that optical media might be any better than USB or SCP. But indeed, malware can infect CD-Rs during the burning process (at least on Windows), and U is of course untrusted. – sampablokuper Dec 26 '13 at 3:41
  • @CarlWitthoft, sandbox idea is interesting; echos Gilles's VM suggestion below. Could be set up to check for various kinds of possible odd behaviour by (or properties of) suspect file F, perhaps based on F's file type, as a supplement to the ClamAV scan. – sampablokuper Dec 26 '13 at 3:46
  • Some discussions of air gaps and data diodes can be found on the blogs of Colin Robbins and Bruce Schneier. Schneier also explains his preference for optical media instead of USB drives. – sampablokuper Jan 1 '14 at 18:37
4

The non-paranoid approach:

  1. Firewall everything for U except SSH from T, start an SSH server on U, upload a public key for a user on T, and copy the file with scp. OR
    Copy the file to an USB key on U, copy it to T.
  2. Analyze the file on T until you're satisfied it's good enough not to break the application you're going to use to read it.
  3. Read the file.

The paranoid approach, if you're worried that plugging the computer into your network will automatically make malware crawl up the cable, and that any file infected by malware can spontaneously jump onto any computer where the file is stored:

  1. On U, print out the video file, frame by frame.
  2. On T, scan the frames and assemble them.
  3. Play the sound on U with some trusted sacrificial loudspeakers (wouldn't want to pop an eardrum) and record it with a microphone on T.

If you aren't fully confident on your capacity to analyze the file for malware that might infect the reader application (step N2), then don't read it on T. Read it inside a virtual machine with no network connection. While it is in theory possible that the malware contains not only a zero-day for your reader application but also a zero-day for your virtual machine software, if you're concerned about such threats, you also need to take into account the threat of receiving bad advice over the Internet. (How do you know I don't work for ████████?)

Don't forget that even in the paranoid approach, you still have to do with the human element: the video could be a convincing meme from a Nigerian prince, or worse.

7

If your adversary has access to U and is able to modify that .mov file, and if you're expecting an imminent threat coming from U, then there's no safe way to copy that file and run it on T.

An active persistent threat will find/pay for zero-day exploits and craft a version of the .mov file that will exploit a vulnerability in your media player, media libraries, codecs, or operating system.

Excluding such cases, I think the best way is to:

  1. Update all the packages on your Linux operating system.

  2. Copy the file from U on a storage medium (USB stick).

  3. Disable all autoplay/autorun features on T and plug the stick in T.

  4. Use the command cp in the command line to copy that file and that file only from the USB stick to T.

  5. Unplug the USB stick.

  6. Run the file using your updated media player.

Using this method you minimize the risk of cross-contamination from the USB stick, and you maintain (to a large extent) an air-gap between T and U.

  • Thank you for this. Any particular reason why you believe crossing the air gap with a USB key with autorun/etc disabled on T would be safer than crossing it by temporarily connecting via LAN only long enough to perform scp? (Especially given Larimer's attack.) – sampablokuper Dec 23 '13 at 18:02
  • 1
    @sampablokuper , no-pro here, but if U is untrusted it is possible that an active connection to U from T can be exploited by U in a way to compromise T. Using USB ensures that there is no active link between T and U, it is like an air-lock (air-gap mentioned by @Adnan). – Samuel Dec 23 '13 at 20:29
  • Air gaps are great ... in principle. Apparently in practice, they're not so much in favour these days: tofinosecurity.com/blog/scada-security-air-gap-debate-over – sampablokuper Jan 1 '14 at 18:31
0

Rather than try to prevent T from being compromised, prevent any compromise from being permanent. Just make T diskless booting a LiveCD, and transfer via disposable USB flash. If you're less paranoid, T can be a VM. If you're really paranoid, use hardware for T that you'll never trust again.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.