1

I'm writing an auto-updater tool that is run with admin permissions. It's job is to download and install files from a tat archive.

The problem is solved to the point where I can verify identity of the file with ecdsa signature. However there is nothing that prevents file from being modified after signature is verified but before it is read.

One solution is to read file into memory and then verify signature of that data. However update files may be several hundreds MB and I would like to avoid eating that much RAM.

Another solution I can think of is to change permissions (at least write) to be only accessible by admin. I'm not sure if it opens any other vector of attack though.

Yet one more solution is to detect if file was modified after signature was verified but before data was read completely. I don't know if OS provide reliable and trusted method to do this.

My updater will work on Windows and OSX.

UPDATE

Apparently, changing owner or file permission won't help if attacker already opened file.

UPDATE 2 I come up with the following solution:

Archiving:

  1. For each archived file also store its ecdsa signature of sha256 digest
  2. Along with archive store its ecdsa signature of its sha256 digest

Extracting:

  1. Open archive, verify its signature
  2. Without closing it, begin unarchiving
  3. Create temporary directory with rwx access by root / administrator only. Forbid all other users
  4. Extract file into that dir, verify its signature, install it into target location. Repeat for each file
  5. Delete temporary directory
  • how much time is elapsing between verification and read? – schroeder Aug 13 '15 at 23:37
  • This is hard to impossible to predict. In code, those are calls that follows each other. But neither guarantees you anything. Moreover, given that it's an archive, reading it will require time. – Kentzo Aug 13 '15 at 23:39
  • ok - but knowing that helps with understanding what potential solutions might work. – schroeder Aug 13 '15 at 23:57
  • Just an idea: what if you encode some kind of footprint. Lets say you generate a code which include 1 byte every N bytes from the original file. While reading the file (assuming buffered reading) you can verify those bytes and stop on any mismatch. Other way would be to lock the file during verification so it can't be written to, and release the lock after reading (not sure if it would be enough). – lepe Aug 14 '15 at 0:53
1

Since you are already using a signature verification method on the file itself, just modify that system a little bit:

  • Sign individual chunks of the file, and store the signatures inline. If your signature takes 32 bytes, and you use a 4,096 byte chunk size, you can have 4,064 bytes data + 32 bytes signature in each chunk.
  • Sign the list of signatures, and store that signature also.
  • To verify the entire file, verify all chunk signatures and the final signature. If you then keep the signatures in RAM while you are reading your file, you can be assured that it has not changed since the time you verified it. Any change will result in an invalid or valid but mismatching signature.

Alternatively, if you cannot store the signatures inline, use a file just for that purpose. Either way, you can basically prove that the file hasn't modified since you verified its contents.

  • Signing chunks of an archive will make extraction rather complicated. Chances are that by writing my own extractor I will introduce more serious issues. – Kentzo Aug 14 '15 at 12:49
0

I haven't tried this, but I know there are APIs for file change notification:

  • I'm not sure if it's reliable or trustable. Someone would need to disassemble and analyze implementation to determine if they can be used for security purposes. – Kentzo Aug 15 '15 at 14:28

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.