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 guidance on using buffer overflow attributes in C #551

Open
david-a-wheeler opened this issue Jun 27, 2024 · 1 comment
Open

Create guidance on using buffer overflow attributes in C #551

david-a-wheeler opened this issue Jun 27, 2024 · 1 comment

Comments

@david-a-wheeler
Copy link
Contributor

david-a-wheeler commented Jun 27, 2024

Background: Many vulnerabilities in C/C++ programs are caused by a read or write outside of a buffer, which can't happen by default in other languages. C++ developers can often prevent this by using various data types, but C can't use those C++ data types, and C++ may, for various reasons, use the C subset. In C, what you have usually is an array. The bounds information typically exists, but there has been no standard way to indicate the bounds nor to automatically check the bounds.

There are emerging attributes in GCC & LLVM/clang to record the active bounds of buffers in a common way, along with mechanisms to check them. Clang has an experimental set of mechanisms which they intend to use to implement checks, and the Linux kernel has started using some of those mechanisms.

Per the LLVM docs, "The bounds annotations are C type attributes appertaining to pointer types. If an attribute is added to the position of a declaration attribute, e.g., int *ptr __counted_by(size), the attribute appertains to the outermost pointer type of the declaration (int *)." Note in this example __counted_by is a macro that expands to attribute((counted_by(T))) which is the standard syntax for all attributes in clang and gcc.

https://lore.kernel.org/lkml/20230504211827.GA1666363@dev-arch.thelio-3990X/T/
https://clang.llvm.org/docs/BoundsSafetyImplPlans.html
https://clang.llvm.org/docs/BoundsSafety.html
https://lwn.net/Articles/946041/

I understand that GCC 12 implements a __counted_by with some significant restrictions, but for some situations that may be enough.

I focused on "counted_by" here, but there are many other annotations being developed to allow direct expressions of bounds. For example:

  • __sized_by(N) : The pointer points to memory that contains N bytes....
  • __ended_by(P) : The pointer has the upper bound of value P, which is one past the last element of the pointer.
  • __null_terminated : The pointer or array is terminated by NULL or 0.
  • __terminated_by(T) : The pointer or array is terminated by T which is a constant expression.

This is probably separate from the "C/C++ Compiler Hardening Guide" but I think many of the same group should be involved.

I don't know if this is "too soon" to create a recommendation, as work is still ongoing. However, the fact that the Linux kernel is adding this for flexible structures suggests that it might be useful to create a guide for early adopters.

@thomasnyman
Copy link
Contributor

This was discussed during the C/C++ Compiler BP Guide call on 2024-08-08.

To summarize that discussion, the bounds annotations would be a good fit for the Compiler Annotations for C and C++ guide, but @GabrielDosReis pointed out that the bounds annotations are still under active development/discussion are are partly overlapping with efforts in the language communities such as the C++ safety profiles.

Consequently, while these are likely to be relevant in the future, it might be better to defer documenting them until there's indications the features have stabilized and there's a few projects that have accumulated real-world experience in using them.

I think it makes sense to keep this issue open and track the status of these from time to time. I'm adding the backlog label to distinguish these from issues that can be actively worked on now. Happy to hear further thoughts on these in this thread though.

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

2 participants