入力データを処理して、足で撃ちます

今日の記事のリンクは通常とは異なります。 これは、ソースコードが分析された1つのプロジェクトではなく、いくつかの異なるプロジェクトでの同じ診断ルールの一連の応答です。 ここで何に興味がありますか？ 実際には、考慮されたコードフラグメントの一部には、アプリケーションでの作業時に再現可能なエラーが含まれていますが、その他には完全に脆弱性（CVE）が含まれています。 さらに、記事の最後で、セキュリティの欠陥のトピックについて少し説明します。

序文

今日記事で検討されるすべてのエラーは、同様のパターンを持っています。

• プログラムは、 stdinストリームからデータを受け取ります。
• データの読み取りが成功したかどうかのチェックが行われます。
• データが正常に読み取られた場合、キャリー文字は行から削除されます。

ただし、考慮されるすべてのフラグメントにはエラーが含まれており、不正な入力に対して脆弱です。 アプリケーションの実行ロジックに違反する可能性のあるユーザーからデータを受信するため、何かを壊そうとする大きな誘惑がありました。 私がやった。



以下の問題はすべて、C、C ++だけでなく、C＃、Javaのコードのエラーも検索するPVS-Studio静的アナライザーによって発見されました。



もちろん、静的アナライザーで問題を見つけるのは良いことですが、見つけて再現することはまったく別の喜びです。 :)

フリースイッチ

最初の疑わしいコードフラグメントは、FreeSWITCH配布キットの一部であるfs_cli.exeモジュールのコードで見つかりました。

static const char *basic_gets(int *cnt) { .... int c = getchar(); if (c < 0) { if (fgets(command_buf, sizeof(command_buf) - 1, stdin) != command_buf) { break; } command_buf[strlen(command_buf)-1] = '\0'; /* remove endline */ break; } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告 ： V1010 CWE-20未チェックの汚染データがインデックスで使用されています： 'strlen（command_buf）'。



アナライザーは、 command_buf配列へのインデックスによる疑わしいアクセスについて警告します。 未検証の外部データがインデックスとして使用されるため、疑わしいと見なされます。 外部-それらは、 stdinストリームからfgets関数を介して取得されるためです。 未検証-使用前に検証が行われなかったため。 式fgets（command_buf、....）！= Command_bufは、この方法ではデータの受信の事実のみをチェックし、その内容はチェックしないため、カウントされません。



このコードの問題は、特定の条件下で、「\ 0」が配列の外側に書き込まれ、未定義の動作が発生することです。 これを行うには、長さゼロの文字列（C言語の観点から長さゼロの文字列、つまり最初の文字が「\ 0」になる文字列）を入力するだけで十分です。



入力に長さゼロの文字列を渡すとどうなるかを推定してみましょう。

• fgets（command_buf、....） -> command_buf ;
• fgets（....）！= command_buf- > false （ その後 、 ifステートメントのブランチは無視されます）;
• strlen（command_buf） -> 0 ;
• command_buf [strlen（command_buf） -1] -> command_buf [-1] 。

おっと！



ここで興味深いのは、このアナライザーの警告が「手で感じられる」ことです。 問題を繰り返すには、次のものが必要です。

• プログラムをこの機能に持ち込みます。
• getchar（）呼び出しが負の値を返すように入力を微調整します。
• fgets関数に、先頭に終端がゼロの行を渡すと、正常に読み取れるはずです。

ソースを少し調べて、問題を再現するための特定のシーケンスを作成しました。

• fs_cli.exeをバッチモードで実行します（ fs_cli.exe -b ）。 さらに手順を実行するには、 fs_cli.exeをサーバーに接続する必要があります。 このためには、たとえば、 FreeSwitchConsole.exeを管理者としてローカルで実行するだけで十分です。
• getchar（）呼び出しが負の値を返すように入力します。
• 先頭に終端ゼロを含む行を入力します（たとえば、「\ 0Oooops」）。
• ....
• 利益！

以下は、問題のビデオ再生です。

Ncftp

同様の問題がNcFTPプロジェクトで発見されましたが、2つの場所で既に遭遇しました。 コードは似ているため、問題のある場所を1つだけ考えてください。

 static int NcFTPConfirmResumeDownloadProc(....) { .... if (fgets(newname, sizeof(newname) - 1, stdin) == NULL) newname[0] = '\0'; newname[strlen(newname) - 1] = '\0'; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告 ： V1010 CWE-20未チェックの汚染データがインデックスで使用されています： 'strlen（newname）'。



ここでは、FreeSWITCHの例とは異なり、コードはより悪く、問題が発生しやすくなっています。 たとえば、読み取りがfgetsを使用して成功したかどうかに関係なく、「\ 0」の書き込みが発生します。 つまり、通常の実行ロジックを破る方法にはさらに多くの可能性があります。 実証済みの方法で行こう-長さゼロのラインを通りましょう。



再現された問題は、FreeSWITCHの場合よりも少し複雑です。 手順のシーケンスを以下に説明します。

• ファイルをダウンロードできるサーバーの起動と接続。 たとえば、 speedtest.tele2.netを使用しました （最終的に、アプリケーションの起動コマンドは次のようになります： ncftp.exe speedtest.tele2.net ）。
• サーバーからファイルをダウンロードします。 ローカルでは、同じ名前で異なるプロパティを持つファイルが既に存在しているはずです。 たとえば、サーバーからファイルをダウンロードして変更し、もう一度ダウンロードコマンドを実行することができます（たとえば、 512KB.zipを取得します ）。
• 文字「N」で始まる行でアクションを選択することに関する質問に答えてください（たとえば、 さあ、楽しみましょう ）。
• 「\ 0」（またはもっと興味深いもの）を入力してください。
• ....
• 利益！

問題の再現もビデオに記録されます。

Openldap

OpenLDAPプロジェクト（より正確には、付随するユーティリティの1つ）では、FreeSWITCHと同じレーキを踏んだ。 改行文字の削除は、行が正常に読み取られた場合にのみ発生しますが、長さゼロの行に対する保護もありません。



コードスニペット：

 int main( int argc, char **argv ) { char buf[ 4096 ]; FILE *fp = NULL; .... if (....) { fp = stdin; } .... if ( fp == NULL ) { .... } else { while ((rc == 0 || contoper) && fgets(buf, sizeof(buf), fp) != NULL) { buf[ strlen( buf ) - 1 ] = '\0'; /* remove trailing newline */ if ( *buf != '\0' ) { rc = dodelete( ld, buf ); if ( rc != 0 ) retval = rc; } } } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告 ： V1010 CWE-20未チェックの汚染データがインデックスで使用されています： 'strlen（buf）'。



問題の本質がより明らかになるように、過剰を捨てます。

 while (.... && fgets(buf, sizeof(buf), fp) != NULL) { buf[ strlen( buf ) - 1 ] = '\0'; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードはNcFTPよりも優れていますが、依然として脆弱です。 fgetsリクエストで、長さゼロの文字列を入力に渡す場合：

• fgets（buf、....） -> buf ;
• fgets（....）！= NULL- > true （ whileループの本体が実行を開始します ）;
• strlen（buf） -1- > 0-1- > -1 ;
• buf [-1] = '\ 0'

性欲

上記のエラーは非常に興味深いものですが（安定して再現されており、「触れる」ことができます（OpenLDAPの問題に手を伸ばせなかった場合を除く））、脆弱性と呼ばれることはできません。問題にはCVE識別子は割り当てられません。



ただし、一部の実際の脆弱性には同じ問題パターンがあります。 以下のコードスニペットは両方とも、libidnプロジェクトに適用されます。



コードスニペット：

 int main (int argc, char *argv[]) { .... else if (fgets (readbuf, BUFSIZ, stdin) == NULL) { if (feof (stdin)) break; error (EXIT_FAILURE, errno, _("input error")); } if (readbuf[strlen (readbuf) - 1] == '\n') readbuf[strlen (readbuf) - 1] = '\0'; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告 ： V1010 CWE-20未チェックの汚染データがインデックスで使用されています： 'strlen（readbuf）'。



状況は似ていますが、記録がインデックス-1で実行された前の例とは異なり、読み取りはここで行われます。 ただし、これは未定義の動作です。 このエラーには、独自のCVE識別子（ CVE-2015-8948 ）が割り当てられています。



問題を検出した後、このコードは次のように変更されました。

 int main (int argc, char *argv[]) { .... else if (getline (&line, &linelen, stdin) == -1) { if (feof (stdin)) break; error (EXIT_FAILURE, errno, _("input error")); } if (line[strlen (line) - 1] == '\n') line[strlen (line) - 1] = '\0'; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

少し驚いた？ それは起こります。 新しい脆弱性、対応するCVE識別子： CVE-2016-6262



PVS-Studio警告 ： V1010 CWE-20未チェックの汚染データがインデックスで使用されています： 'strlen（line）'。



別の試みでは、入力文字列の長さのチェックを追加することで問題が修正されました。

 if (strlen (line) > 0) if (line[strlen (line) - 1] == '\n') line[strlen (line) - 1] = '\0';
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

日付を見てみましょう。 コミット「クローズ」CVE-2015-8948-08/10/2015。 CVE-2016-62-62-2016年1月14日のクローズをコミットします。 つまり、上記の修正の差は5か月です！ ここでは、コード記述の初期段階でエラーを検出するなどの静的分析の利点について思い出します...

静的分析とセキュリティ

これ以上のコード例はありませんが、代わりに統計と推論があります。 このセクションでは、著者の意見と読者の意見がこの記事の以前よりもはるかに一致しない場合があります。



ご注意 同様のトピックに関する別の記事を読むことをお勧めします-「 PVS-Studioはどのように脆弱性を見つけるのに役立ちますか？ 」。 単純なエラーのように見える脆弱性の興味深い例があります。 さらに、その記事では、用語と、セキュリティトピックについて懸念がある場合に静的分析が必要な理由について少し説明しました。



過去10年間に発見された脆弱性の数に関する統計を見て、状況を評価しましょう。 CVE Details Webサイトからデータを取得しました。

興味深い状況が迫っています。 2014年まで、記録されたCVEの数は6,000ユニットのマークを超えていませんでした。 しかし、2017年の統計はもちろん、ここで最も興味深いものに見えます-絶対的なリーダー（14,714ユニット）です。 現在-2018-年については、まだ終了していませんが、すでに記録を破っています-15,310台。



これは、すべての新しいソフトウェアがふるいのような穴でいっぱいであることを意味しますか？ 私は考えていない、そしてここに理由がある：

• 脆弱性のトピックに対する関心の高まり。 確かに、あなたがセキュリティのトピックにあまり近くなくても、セキュリティのトピックに関する記事、メモ、レポート、ビデオに繰り返し出くわします。 言い換えると、一種の「誇大広告」が作成されました。 悪いですか？ おそらくない。 結局のところ、開発者はアプリケーションのセキュリティをより重視しているという事実に帰着します。これは良いことです。
• 開発されたアプリケーションの数の増加。 より多くのコード-統計を補充する脆弱性が発生する可能性が高くなります。
• 脆弱性検索ツールとコード品質保証の改善。 より多くの需要->より多くの供給。 アナライザー、ファザー、およびその他のツールはより高度になり、脆弱性を探したい人の手に渡ります（バリケードのどちらの側にいても）。

したがって、新たなトレンドを否定的なものと呼ぶことはできません。出版社は情報セキュリティについてより懸念しており、問題を見つけるためのツールが改善されており、これは間違いなく肯定的です。



これは、「入浴」せずにリラックスできるということですか？ 私はそうは思いません。 アプリケーションのセキュリティトピックが心配な場合は、できるだけ多くのセキュリティ対策を講じる必要があります。 これは、ソースコードがパブリックドメインにある場合に特に当てはまります。

• 外部の脆弱性の埋め込みの影響を受けやすい。
• 悪用の目的でアプリケーションの穴に興味がある「紳士」によって「プロービング」される傾向があります。 この場合の希望者はあなたをもっと助けることができますが。

プロジェクトをオープンソースで翻訳する必要がないとは言いたくありません。 適切な品質/安全管理を念頭に置いてください。



静的解析はそのような追加の手段ですか？ はい 静的分析は、将来現実になる可能性のある潜在的な脆弱性を検出するのに役立ちます。



多くの人が脆弱性をかなり高レベルの現象であると考えているように思えます（私は間違いだと思います）。 はい、いいえ。 単純なプログラミングエラーのように見えるコードの問題も深刻な脆弱性です。 繰り返しになりますが、このような脆弱性の例は、 前述の記事で提供されています 。 「単純な」間違いを過小評価しないでください。

おわりに

入力データの長さをゼロにすることができ、これも考慮する必要があることを忘れないでください。



脆弱性を伴うすべての誇大広告が単なる誇大広告であるかどうか、または問題が存在する場合は自分でやるという結論。



私の場合は、プロジェクトPVS-Studioをまだ試していない場合は試してみない限りです。



最高！

この記事を英語圏の聴衆と共有したい場合は、翻訳へのリンクを使用してください：セルゲイヴァシリエフ。 入力データを処理するときに足で自分自身を撃つ