😷 📲 👨🏿‍✈️ Glibcライブラリのテスト実験 💃🏾 👩‍⚖️ 🧒

PVS-Studioを使用してglibcライブラリを確認する実験を実施しました。実験の目的は、アナライザーがLinuxプロジェクトをどの程度正常にチェックできるかを確認することです。これまでのところ悪いことができます。非標準の拡張機能を使用しているため、多くの誤検知があります。しかし、それでも面白いものを見つけることができました。

glibc

glibc -GNU Cライブラリ（GNUライブラリ）。 Glibcは、システムコールと、open、malloc、printfなどの基本機能を提供するCライブラリです。 Cライブラリは、すべての動的にリンクされたプログラムに使用されます。 GNUオペレーティングシステム用のFree Software Foundationによって作成されています。 glibcはGNU LGPLライセンスの下でリリースされています。

ウィキペディアからの改編： glibc 。

少し前に、新しいバージョンのglibcライブラリがリリースされたというニュースがインターネットに登場しました。このため、 PVS-Studioアナライザーを使用してこのライブラリをテストする必要がありました。つまり、glibc-2-19-90バージョンがチェックされました。残念ながら、数週間は気が散りましたので、今だけ記事を書く時間を見つけました。私はいくつかの静的アナライザーの大規模な比較に忙しかった。これは、CppcheckやVisual Studio 2013の静的アナライザーよりも優れているものを尋ねることを止めないため、私たちにとって非常に重要なタスクです。したがって、glibcは少し待たなければなりませんでした。

ひどいものを見つけるとは思っていませんでしたが、実際には見つかりませんでした。 glibcライブラリは非常に高品質であり、多くのパーサーによって検証されています。少なくとも、これらは次のとおりです。

コベリティ
Clang;
Cppcheck。

したがって、少なくとも何かを見つけることは、すでに大きな成果です。

分析の複雑さは何ですか

静的分析ツールの内部キッチンに慣れていないため、非常にシンプルなユーティリティのように見えます。そうではありません。これらは非常に複雑なプログラムです。

RATSなどのツールはわかりにくい場合があります。誰かがRATSコードを見ると、それはファイル内の特定の関数名の単なる検索であることがわかりました。このツールは、静的コードアナライザーとも呼ばれます。ただし、実際のコードアナライザーが行うこととは非常に異なります。静的分析は、正規表現による検索ではありません[ 1 ]。

Linuxバージョンは、再コンパイルされた実行可能モジュールとまったく同じではないことを繰り返しました[ 2 ]。実行可能モジュールとソフトウェア製品の間にギャップがあります。障害の1つは、特定の拡張機能などのサポートです。

それは何ですか、第三者は完全に理解不能です。ここから見ると、strcmp（）関数のプログラム呼び出しで：

cmpres = strcmp (newp->from_string, root->from_string);

そして彼は、この行が前処理後にどのような恐怖を明らかにするのか、そしてどの非標準の拡張機能が使用されるのかについても疑っていません。具体的には、この場合、文字列は次のようになります。

 cmpres = __extension__ ({ size_t __s1_len, __s2_len; (__builtin_constant_p (newp->from_string) && __builtin_constant_p (root->from_string) && (__s1_len = strlen (newp->from_string), __s2_len = strlen (root->from_string), (!((size_t)(const void *)((newp->from_string) + 1) - (size_t)(const void *)(newp->from_string) == 1) || __s1_len >= 4) && (!((size_t)(const void *)((root->from_string) + 1) - (size_t)(const void *)(root->from_string) == 1) || __s2_len >= 4)) ? __builtin_strcmp (newp->from_string, root->from_string) : (__builtin_constant_p (newp->from_string) && ((size_t)(const void *)((newp->from_string) + 1) - (size_t)(const void *)(newp->from_string) == 1) && (__s1_len = strlen (newp->from_string), __s1_len < 4) ? (__builtin_constant_p (root->from_string) && ((size_t)(const void *)((root->from_string) + 1) - (size_t)(const void *)(root->from_string) == 1) ? __builtin_strcmp (newp->from_string, root->from_string) : (__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const char *) (root->from_string); int __result = (((const unsigned char *) (const char *) (newp->from_string))[0] - __s2[0]); if (__s1_len > 0 && __result == 0) { __result = (((const unsigned char *) (const char *) (newp->from_string))[1] - __s2[1]); if (__s1_len > 1 && __result == 0) { __result = (((const unsigned char *) (const char *) (newp->from_string))[2] - __s2[2]); if (__s1_len > 2 && __result == 0) __result = (((const unsigned char *) (const char *) (newp->from_string))[3] - __s2[3]); } } __result; }))) : (__builtin_constant_p (root->from_string) && ((size_t)(const void *)((root->from_string) + 1) - (size_t)(const void *)(root->from_string) == 1) && (__s2_len = strlen (root->from_string), __s2_len < 4) ? (__builtin_constant_p (newp->from_string) && ((size_t)(const void *)((newp->from_string) + 1) - (size_t)(const void *)(newp->from_string) == 1) ? __builtin_strcmp (newp->from_string, root->from_string) : (- (__extension__ ({ const unsigned char *__s2 = (const unsigned char *) (const char *) (newp->from_string); int __result = (((const unsigned char *) (const char *) (root->from_string))[0] - __s2[0]); if (__s2_len > 0 && __result == 0) { __result = (((const unsigned char *) (const char *) (root->from_string))[1] - __s2[1]); if (__s2_len > 1 && __result == 0) { __result = (((const unsigned char *) (const char *) (root->from_string))[2] - __s2[2]); if (__s2_len > 2 && __result == 0) __result = (((const unsigned char *) (const char *) (root->from_string))[3] - __s2[3]); } } __result; })))) : __builtin_strcmp (newp->from_string, root->from_string)))); });

アナライザーは、そのようなイベントの順番に対応する準備ができておらず、そのような構成で無意味な誤ったメッセージを生成することがあります。

簡単な例で偽のメッセージについて説明します。次のコード行があるとします。

 assert(MAP_FAILED == (void *) -1);

assert（）マクロは、次のコードに展開されます。

 ((((void *) -1) == (void *) -1) ? (void) (0) : __assert_fail ("((void *) -1) == (void *) -1", "loadmsgcat.c", 840, __PRETTY_FUNCTION__));

PVS-Studioアナライザーは、比較に関して誤った警告を生成します（（（void *）-1）==（void *）-1）：

V501 '=='演算子の左右に同じ部分式があります：（（void *）-1）==（void *）-1 loadmsgcat.c 840

これには驚きません。 Visual C ++を使用してビルドされたプログラムの開発中に、これらすべてを既に実行しました。また、あらゆる種類の興味深い珍しいものがたくさんあります。何が何であるかを分析者に理解させるために、多くの作業を行う必要があります。無害で、MAP_FAILEDマクロが「（void *）-1」であることをチェックするだけの「アサート」マクロを扱っていることを理解するように彼に教える必要があります。これらはすべて、Visual C ++で既に行われています。しかし、Linuxの場合はありません。

このような構造で正しく動作する機能は、他のコンパイラをサポートする作業の大部分を占めています。外側では、この作品は見えません。ただし、コンパイラと標準ライブラリの機能を調べる必要があります。これらの機能は、調査、サポート、およびテストする必要があります。

あなたが地獄を見ることができるように、私は小さなクリックを開いたことを願っています。将来、静的解析ツールの開発の複雑さを示す一連の記事を書く予定です。面白いと思います。

疑わしいコードの断片が見つかりました

glibcプロジェクトは多くのツールでテストされていますが、それでも面白いものを見つけることができました。コードのこれらのセクションを見てみましょう。

奇妙な表現

 char *DCIGETTEXT (....) { .... /* Make CATEGORYVALUE point to the next element of the list. */ while (categoryvalue[0] != '\0' && categoryvalue[0] == ':') ++categoryvalue; .... }

V590この表現を調べることを検討してください。表現が過剰であるか、誤植が含まれています。 dcigettext.c 582

条件は次のように簡略化できます。

 while (categoryvalue[0] == ':')

おそらくこれは間違いではなく、条件の最初の部分（categoryvalue [0]！= '\ 0'）は単に不要です。ただし、突然次のように記述される必要があります。

 while (categoryvalue[0] != '\0' && categoryvalue[0] != ':')

検証前のポインターの逆参照

必ずしも、この場所は危険です。おそらく、ポインターがゼロになることはありません。しかし、それでも：

 static enum clnt_stat clntraw_call (h, proc, xargs, argsp, xresults, resultsp, timeout) CLIENT *h; u_long proc; xdrproc_t xargs; caddr_t argsp; xdrproc_t xresults; caddr_t resultsp; struct timeval timeout; { struct clntraw_private_s *clp = clntraw_private; XDR *xdrs = &clp->xdr_stream; .... if (clp == NULL) return RPC_FAILED; .... }

V595 nullptrに対して検証される前に、「clp」ポインターが使用されました。行を確認してください：145、150。clnt_raw.c 145

同様の欠陥がこのファイルで次に見られます：V595 nullptrに対して検証される前に、 'clp'ポインターが利用されました。行を確認：232、235。clnt_raw.c 232

危険なコードの別の例：

 int __nss_getent_r (....) { .... if (res && __res_maybe_init (&_res, 0) == -1) { *h_errnop = NETDB_INTERNAL; *result = NULL; return errno; } .... if (status == NSS_STATUS_TRYAGAIN && (h_errnop == NULL || *h_errnop == NETDB_INTERNAL) && errno == ERANGE) }

V595 nullptrに対して検証される前に、「h_errnop」ポインターが使用されました。行を確認：146、172。getnssent_r.c 146

条件if（res && __res_maybe_init（＆_res、0）== -1）が満たされると、関数はエラーに関する情報を返します。そうすることで、ポインター「h_errnop」と「result」を逆参照します。ただし、これらのポインターはNULLである可能性があります。この結論は、以下のコードを調べることで引き出すことができます。

危険な最適化（脆弱性）

 char * __sha256_crypt_r (key, salt, buffer, buflen) const char *key; const char *salt; char *buffer; int buflen; { .... unsigned char temp_result[32] .... memset (temp_result, '\0', sizeof (temp_result)); .... .... // temp_result    }

V597コンパイラーは、「temp_result」バッファーのフラッシュに使用される「memset」関数呼び出しを削除できました。 RtlSecureZeroMemory（）関数を使用して、プライベートデータを消去する必要があります。 sha256-crypt.c 385

コンパイラには、リリースバージョンをコンパイルするときにmemset（）関数呼び出しを削除する権利があります。より正確には、彼は法律上だけでなく、最適化のためにこれを行う義務もあります。バッファ 'temp_result'は、memset（）関数を呼び出した後はどこでも使用されないため、関数呼び出し自体も不要です。

個人データが消去されないため、脆弱性に対処しています。 memset（）関数は、より適切なものに置き換える必要があります。アナライザーはRtlSecureZeroMemory（）を提供しますが、これはもちろんLinuxにはありません。しかし、類似物があります。

同様の状況：V597コンパイラーは、「temp_result」バッファーのフラッシュに使用される「memset」関数呼び出しを削除できます。 RtlSecureZeroMemory（）関数を使用して、プライベートデータを消去する必要があります。 sha512-crypt.c 396

未定義の動作

glibcライブラリはできるだけ移植性の高いものにすべきだと思われます。ただし、携帯性の観点から安全とは言えない多くのせん断構造があります。

シフトに関するC標準が示すことは次のとおりです。

整数のプロモーションは、各オペランドで実行されます。結果の型は、昇格された左オペランドの型です。右のオペランドの値が負であるか、昇格した左のオペランドの幅以上である場合、動作は未定義です。

E1 << E2の結果は、E1の左シフトE2ビット位置です。空きビットはゼロで埋められます。 E1に符号なしの型がある場合、結果の値はE1 * 2 pow E2で、結果の型で表現可能な最大値よりも1を法として減じられます。 E1に符号付きのタイプと非負の値があり、E1 * 2 pow E2が結果のタイプで表現できる場合、それが結果の値です。それ以外の場合、動作は未定義です。

5 E1 >> E2の結果は、E1を右シフトしたE2ビット位置です。 E1に符号なしの型がある場合、またはE1に符号付きの型と非負の値がある場合、結果の値はE1 / 2 pow E2の商の整数部になります。 E1に符号付きタイプと負の値がある場合、結果の値は実装定義です。

標準から、負の数をシフトするのは間違っているということです。ただし、これはglibcライブラリでは非常に一般的な操作です。

左シフトの例：

 static void init_cacheinfo (void) { .... count_mask = ~(-1 << (count_mask + 1)); .... }

V610未定義の動作。シフト演算子 '<<を確認してください。左のオペランド '-1'は負です。 cacheinfo.c 645

右シフトの例：

 utf8_encode (char *buf, int val) { .... *buf = (unsigned char) (~0xff >> step); .... }

式「〜0xff」のタイプは「int」で、-256です。

以下は、不正確なシフトを観察できるすべての場所のリストです。

strxfrm_l.c 68
clock_nanosleep.c 38
ifaddrs.c 786
xdr_intXX_t.c 35
xdr_intXX_t.c 41
private.h 327
private.h 331
zic.c 696
zdump.c 212
zdump.c 216
timer_create.c 47
timer_create.c 49
loop.c 331
loop.c 437
mktime.c 207
mktime.c 208
mktime.c 211
mktime.c 212
mktime.c 230
mktime.c 298
mktime.c 298
ld-collate.c 298

初期化されていない変数を使用する

 static int send_vc(....) { .... int truncating, connreset, resplen, n; .... #ifdef _STRING_ARCH_unaligned *anssizp2 = orig_anssizp - resplen; *ansp2 = *ansp + resplen; #else .... } V614 Uninitialized variable 'resplen' used. res_send.c 790

誤った文字列フォーマット

一部の場所では、 '％u'を使用して署名付き変数を出力します。一部の場所では、「％d」を使用して符号なし変数を出力します。これらはもちろん些細なことですが、言及する価値もあります。

例：

 typedef unsigned int __uid_t; typedef __uid_t uid_t; int user2netname (...., const uid_t uid, ....) { .... sprintf (netname, "%s.%d@%s", OPSYS, uid, dfltdom); .... }

V576形式が正しくありません。 'sprintf'関数の4番目の実引数を確認することを検討してください。整数型のSIGNED引数が必要です。 netname.c 51

その他の関連記事：

'printf'関数の2番目の実引数を確認することを検討してください。整数型のSIGNED引数が必要です。 locarchive.c 1741
'printf'関数の4番目の実引数を確認することを検討してください。整数型のSIGNED引数が必要です。 locarchive.c 1741
'fprintf'関数の5番目の実引数を確認することを検討してください。整数型のSIGNED引数が必要です。 res_debug.c 236
'sprintf'関数の3番目の実引数を確認することを検討してください。 UNSIGNED整数型の引数が必要です。 inet_net_ntop.c 134
'sprintf'関数の4番目の実引数を確認することを検討してください。整数型のSIGNED引数が必要です。 ns_print.c 500
'sprintf'関数の5番目の実引数を確認することを検討してください。整数型のSIGNED引数が必要です。 ns_print.c 500
'sprintf'関数の3番目の実引数を確認することを検討してください。整数型のSIGNED引数が必要です。 ns_print.c 572
'sprintf'関数の4番目の実引数を確認することを検討してください。整数型のSIGNED引数が必要です。 ns_print.c 572
'sprintf'関数の5番目の実引数を確認することを検討してください。整数型のSIGNED引数が必要です。 ns_print.c 572
'sprintf'関数の3番目の実引数を確認することを検討してください。 UNSIGNED整数型の引数が必要です。 ns_print.c 628
'sprintf'関数の4番目の実引数を確認することを検討してください。 UNSIGNED整数型の引数が必要です。 ns_print.c 628
'sprintf'関数の5番目の実引数を確認することを検討してください。 UNSIGNED整数型の引数が必要です。 ns_print.c 628
'sprintf'関数の3番目の実引数を確認することを検討してください。整数型のSIGNED引数が必要です。 ns_print.c 645
'sprintf'関数の3番目の実引数を確認することを検討してください。 UNSIGNED整数型の引数が必要です。 ns_print.c 685
'printf'関数の2番目の実引数を確認することを検討してください。整数型のSIGNED引数が必要です。 nis_print.c 209
'printf'関数の2番目の実引数を確認することを検討してください。整数型のSIGNED引数が必要です。 sprof.c 480

おわりに

Linuxの世界からのコードのチェックを開始するのに良いプロジェクトは選ばれませんでした。彼は質が高すぎる。 :)間違いについて興味深い記事を書くのは難しいです。しかし、それは問題ではありません。 Linuxの他の多くの有名で興味深いプロジェクトを待っています。PVS-Studioアナライザーの機能を実証するために確認します。

サイトリンク

アンドレイ・カルポフ。静的分析と正規表現。
ドミトリー・カチェンコ。 PVS-StudioおよびCppCatのテクニカルディレクターであるAndrei Karpovとの会話。

質問への回答

多くの場合、記事には同じ質問が寄せられます。ここでそれらに対する回答を収集しました： PVS-StudioおよびCppCatバージョン2014に関する記事の読者からの質問への回答。

Glibcライブラリのテスト実験