This article was originally published on the Red Hat Customer Portal. The information may no longer be current.
FORTIFY_SOURCE provides lightweight compile and runtime protection to some memory and string functions (original patch to gcc was submitted by Red Hat). It is supposed to have no or a very small runtime overhead and can be enabled for all applications and libraries in an operating system. The concept is basically universal meaning it can be applied to any operating system, but there are glibc specific patches available in gcc-4 onwards. In gcc, FORTIFY_SOURCE normally works by replacing some string and memory functions with their *_chk counterparts (builtins). These functions do the necessary calculations to determine an overflow. If an overflow is found, the program is aborted; otherwise control is passed to the corresponding string or memory operation functions. Again all this is normally done in assembly so the overhead is really minimal.
While there are some technical articles which talk about FORTIFY_SOURCE in detail, this article discusses broad objectives of this technology and how it can help developers prevent some vulnerabilities related to buffer overflows.
How does FORTIFY_SOURCE actually work
As mentioned earlier, depending on the code, gcc can detect buffer overflows during compile time and runtime.
Consider a buffer of fixed size which is declared as:
char buf[5];
Here are possible scenarios FORTIFY_SOURCE can effectively work with:
- Fixed data being copied into
buf
memcpy (buf, foo, 5);
strcpy (buf, "abcd");
In this case size of the data being copied into buf
is known (5 bytes in first case and 4 chars plus a null byte in the second case), therefore FORTIFY_SOURCE can easily determine at compile time that no buffer overflow is possible, so memcpy/strcpy can be called directly or even inlined.
- Again, fixed data being copied into
buf
memcpy (buf, foo, 6);
strcpy (buf, "abcde");
Again size of the data is known, but seems to be incorrect. The compiler can detect buffer overflows at compile time. It issues warnings at compile time, and calls the checking alternatives at runtime.
- Variable data being copied into
buf
memcpy (buf, foo, n);
strcpy (buf, bar);
The compiler knows the number of bytes remaining in object, but doesn't know the length of the actual copy that will happen at runtime. FORTIFY_SOURCE replaces memcpy or strcpy with wrapper functions __memcpy_chk
or __strcpy_chk
which checks if a buffer overflow happened. If buffer overflow is detected, __chk_fail ()
is called (the normal action is to abort () the application, perhaps by writing some message to stderr).
- Variable data copied into buffer whose size is not known:
memcpy (p, q, n);
strcpy (p, q);
This is not check-able at compile time or at runtime. FORTIFY_SOURCE cannot be used to protect against overflows if they occur.
Functions protected by FORTIFY_SOURCE
Memcpy, memset, stpcpy, strcpy, strncpy, strcat, strncat, sprintf, snprintf, vsprintf, vsnprintf, gets(3), and wide character variants thereof. For some functions, argument consistency is checked; for example, a check is made that open(2) has been supplied with a mode argument when the specified flags include O_CREAT.
How to enable FORTIFY_SOURCE
During compile D_FORTIFY_SOURCE macro needs to be set in order to enable FORTIFY_SOURCE. There are two levels of checking which are implemented. Setting the macro to 1 will enable some checks (the man page says that "checks that shouldn't change the behavior of conforming programs are performed"), while setting it to 2 adds some more checking.
The difference between -D_FORTIFY_SOURCE=1 and -D_FORTIFY_SOURCE=2
is e.g. for:
struct S {
struct T {
char buf[5];
int x;
} t;
char buf[20];
} var;
With -D_FORTIFY_SOURCE=1, "strcpy (&var.t.buf[1], "abcdefg");"
is not considered an overflow (object is whole VAR), while with -D_FORTIFY_SOURCE=2 "strcpy (&var.t.buf[1], "abcdefg");"
will be considered a buffer overflow.
Another difference is that with -D_FORTIFY_SOURCE=2, "%n" in format strings of the most common *printf family functions is allowed only if the format string is stored in read-only memory (usually string literals, gettext's _("%s string %n") is fine too). Usually, when an attacker attempts to exploit a format string vulnerability, the "%n" is injected by the attacker, so it is necessarily a writable memory.
In conclusion FORTIFY_SOURCE is lightweight and quite effective at controlling some categories of overflows, but again like any other security technology it is not perfect and should be enabled in combination with others.
執筆者紹介
Huzaifa Sidhpurwala is a Senior Principal Product Security Engineer - AI security, safety and trustworthiness, working for Red Hat Product Security Team.
類似検索
チャンネル別に見る
自動化
テクノロジー、チームおよび環境に関する IT 自動化の最新情報
AI (人工知能)
お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート
オープン・ハイブリッドクラウド
ハイブリッドクラウドで柔軟に未来を築く方法をご確認ください。
セキュリティ
環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報
エッジコンピューティング
エッジでの運用を単純化するプラットフォームのアップデート
インフラストラクチャ
世界有数のエンタープライズ向け Linux プラットフォームの最新情報
アプリケーション
アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細
オリジナル番組
エンタープライズ向けテクノロジーのメーカーやリーダーによるストーリー
製品
ツール
試用、購入、販売
コミュニケーション
Red Hat について
エンタープライズ・オープンソース・ソリューションのプロバイダーとして世界をリードする Red Hat は、Linux、クラウド、コンテナ、Kubernetes などのテクノロジーを提供しています。Red Hat は強化されたソリューションを提供し、コアデータセンターからネットワークエッジまで、企業が複数のプラットフォームおよび環境間で容易に運用できるようにしています。
言語を選択してください
Red Hat legal and privacy links
- Red Hat について
- 採用情報
- イベント
- 各国のオフィス
- Red Hat へのお問い合わせ
- Red Hat ブログ
- ダイバーシティ、エクイティ、およびインクルージョン
- Cool Stuff Store
- Red Hat Summit