Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

create doesn't zero the struct #30

Closed
talex5 opened this issue Jul 6, 2014 · 5 comments
Closed

create doesn't zero the struct #30

talex5 opened this issue Jul 6, 2014 · 5 comments

Comments

@talex5
Copy link
Contributor

talex5 commented Jul 6, 2014

The structure returned by create isn't initialised. In a Mirage service, it might contain confidential data (e.g. TLS key material), which could easily be leaked.

Possibly this should be fixed in OCaml's Bigarray (and String.create), but at the very least, the documentation should mention this.

@avsm
Copy link
Member

avsm commented Jul 6, 2014

Heh, I was looking into this just now while typing a reply to your email. I think it's better to be safe rather than sorry and specifically zero out structures created via Cstruct.create (no guarantee can be made for of_bigarray, but this is generally used with pre-allocated pages or mmaped files).

@hannesm
Copy link
Member

hannesm commented Jan 11, 2016

I assume this can be closed, now that we have memset!? Maybe the documentation for create should explicitly say that the buffer is not zeroed out?

@talex5
Copy link
Contributor Author

talex5 commented Jan 12, 2016

The problem is that it isn't cleared by default. Perhaps we should make create zero it, and have a separate create_unsafe for people who want the current behaviour?

@hannesm
Copy link
Member

hannesm commented Jan 12, 2016

I don't see the benefit of zeroing it out - I usually need to fill the byte vector with some data (which I control), maybe a ?fill keyword for create would be good?

If you're concerned about confidential data, I don't think the Cstruct.create should worry about it (since there may be any number of functions which expose the contents of raw memory, such as Bigarray/String.create). Instead, a way to properly erase key material (+derived data) is needed (this can only work with modifications to the runtime afaics). IMHO zeroing out the cstruct gives a false sense of security, the potential leak should be prevented at the origin, not at a later point when reusing the piece of memory.

@talex5
Copy link
Contributor Author

talex5 commented Jan 14, 2016

It's not just key material that's confidential (though manually erasing that at free time might be a good idea anyway). Any information leak is a potential problem. It's also a reliability problem, since you tend to get zeroes when testing but other values after things have been running for a while.

In my opinion, all sources of uninitialised data should be marked unsafe. We should probably patch String.create to zero things out too, although it's unlikely we use it much in Mirage.

It would be good if there was a safe way to create and initialise a cstruct. e.g. in mirage-qubes I have a function:

let make_msg_header ~ty ~path ~data_len =
  let msg = Cstruct.create sizeof_msg_header in
  set_msg_header_ty msg (qdb_msg_to_int ty);
  set_fixed_string (get_msg_header_path msg) path;
  Cstruct.memset (get_msg_header_padding msg) 0;
  set_msg_header_data_len msg (Int32.of_int data_len);
  msg

Perhaps cstruct could auto-generate such functions?

djs55 added a commit to djs55/ocaml-cstruct that referenced this issue Mar 12, 2016
This improves the situation described in mirage#30

Signed-off-by: David Scott <dave.scott@docker.com>
talex5 added a commit to talex5/ocaml-cstruct that referenced this issue May 14, 2016
The new `create_unsafe` function can be used if you want to trade safety
for speed.

Fixes mirage#30
talex5 added a commit to talex5/ocaml-cstruct that referenced this issue May 17, 2016
The new `create_unsafe` function can be used if you want to trade safety
for speed.

Fixes mirage#30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants