Potential bindgen footguns or general security considerations

[droogie]

Hello,

I'm looking at using bindgen but I am also new to Rust and was curious if you could provide guidance on any potential footguns or general security considerations.

Since interfacing with FFI is inherently unsafe, I want to ensure that I am aware of the potential dangers and common mistakes that could be made with bindgen, which would be useful for when I choose to use it or when reviewing a project that uses it already.

Based on the bindgen user guide, I believe these are the major concerns to be aware of (plus some questions):

• Ensure Allowlisting/Blocklisting is used to only generate bindings for necessary / wanted types, functions, etc.
• Be aware of the potential derivation of Copy and Clone traits on types which should not be
  • Example provided are pthread mutexes, can you think of other examples to be aware of?
• Be aware of the potential derivation of the Debug trait on types for some that should not be
  • Example provided is an enum, my understanding is that it is unsafe to pass enums over FFI boundaries due to enums being implementation defined in C. I'm under the impression that enums should maybe be blacklisted but the fact that it's only mentioned for Debug trait (I believe only used for pretty printing?) clearly I'm misunderstanding the enum risk over FFI boundaries, could someone explain?
• Be aware of implementing Default traits for structures
  • Is the default behavior to the structures defined with zeroed memory or is there a chance of uninitialized memory being used?

Are there other concerns or considerations I should be aware of?

Thanks!

[pvdrz]

Hi 👋

I'd say the most general security considerations would be included in the rustonomicon as bindgen doesn't provide any extra security safeguards itself, just the convenience of not writing bindings by hand.

Regarding your questions:

Ensure Allowlisting/Blocklisting is used to only generate bindings for necessary / wanted types, functions, etc.

This is something that is very nice to have, but I'd say it is easier to avoid footguns if you keep all the generated bindings in a private module and only expose the parts you actually need. In that way, you only have to blocklist stuff you can't have (like code that can't be translated by bindgen)

Example provided are pthread mutexes, can you think of other examples to be aware of?

Nothing comes up from the top of my head but I'd say that anything that shouldn't be accessed from two different places is a potential example. For example, if you were to have some C code that gives you a pointer that should be treated as unique, you shouldn't allow cloning it from the Rust side.

Other case could be types that require a custom Clone where #[derive(Clone)] wouldn't be appropriate. Reference counting types would be a good example here, you don't want to just copy the whole RC and call it for a day, but increase the counter and then copy the pointer. Maybe some OS resource handles would fall under this category as well.

Example provided is an enum, my understanding is that it is unsafe to pass enums over FFI boundaries due to enums being implementation defined in C.

I'm not sure but I suspect the reason is just because enums in C are used very loosely in replace of integers. So in the example they show, they define a C enum and afterwards do a bitwise OR between two values of it. That value won't be legal in rust if represented as a rust enum because rust enums are closed and it is actually UB to produce such a value. I'd argue that deriving debug would be the least of your worries in such cases but 🤷.

I'm under the impression that enums should maybe be blacklisted but the fact that it's only mentioned for Debug trait (I believe only used for pretty printing?) clearly I'm misunderstanding the enum risk over FFI boundaries, could someone explain?

I wouldn't go as far as say that you should blocklist all enums, the main issue is assuming that when you receive a C enum, it will only include certain values. Bindgen represents C enums as rust integers by default to avoid such assumptions.

Is the default behavior to the structures defined with zeroed memory or is there a chance of uninitialized memory being used?

Default just provides an unified way to have a useful de-facto value for a type. Sometimes you want to avoid this just because you don't want to provide the user with a way to create values of a type from outside your library. Other times is because you cannot derive it, Any non-null pointer type is a good example of this, you cannot create such a pointer unless you have the value to point to, so deriving Default in such cases is undesired.

I think from here you can get the general vibe of "creating invalid values is a very common pitfall". So my most general recommendation would be to check what can cause undefined behavior and then check if your bindings are doing such a thing.