ラック・セキュリティごった煮ブログ

セキュリティエンジニアがエンジニアの方に向けて、 セキュリティやIT技術に関する情報を発信していくアカウントです。

【お知らせ】2021年5月10日~リニューアルオープン!今後はこちらで新しい記事を公開します。

株式会社ラックのセキュリティエンジニアが、 エンジニアの方向けにセキュリティやIT技術に関する情報を発信するブログです。(編集:株式会社ラック・デジタルペンテスト部)
当ウェブサイトをご利用の際には、こちらの「サイトのご利用条件」をご確認ください。

デジタルペンテスト部提供サービス:ペネトレーションテスト

Open Source Vulnerabilitiesの話

f:id:lac_devblog:20210908182351j:plain

お久しぶりです。
「早くAIに仕事を奪われて楽になりたい!」と祈っているセキュ松です。

今年の2月にOSVが発表されましたね!
Google様の力で、主要なOSSを対象として継続的にファジングを実施し、発見された脆弱性のDBを作っていく夢のようなプロジェクトです。
6月24日に「OSVで使用されているスキーマが良い感じになってきたよ!」という記事が出たので、今回は実際にOSVに触れていきたいと思います。

security.googleblog.com

ファジングとは?

ファジングとは、ソフトウェアや組み込み機器に未知の脆弱性が含まれていないかを検出するテスト手法です。
極端に長い文字列や記号を含んだ文字列など、問題が起こりそうなデータを大量に送信し、異常な動作が発生しないかを確認します。

OSVとは?

OSV(Open Source Vulnerabilities)とは、Googleからリリースされた、主要なOSS脆弱性情報を一元管理するためのデータベースです。
Go、Rust、Python、DWFのソフトウェアを対象とした脆弱性のデータベースを1つに集約することで、OSSの開発者が脆弱性を追跡しやすくし、対応を容易にすることを目的としています。
OSVによって集約されている、主要なOSSの各言語の脆弱性データベースは下記になります。

これらのデータベースに集められた脆弱性が、OSVに集約されています。

OSVは実際に下記のURLにて稼働しています。

osv.dev

 

また、OSV自身もOSSとして公開されていて、リポジトリは下記になります。

github.com

OSS-Fuzzとは?

OSS-Fuzzとは、スケーラブルで分散実行可能なシステムにより、主要なOSS脆弱性を継続的に発見することを目的としたプロジェクトです。
ファジングに用いられているのはlibFuzzer、AFL++、Honggfuzzなどのファジングエンジンです。
これらのファジングエンジンを用いた結果がまとめられています。
OSSとしても公開されていて、リポジトリは下記になります。

github.com

 

また、OSS-Fuzzの対象となっているOSSは下記から確認することができます。

9月6日時点で535ものOSSが対象となっていることがわかります。
https://github.com/google/oss-fuzz/tree/master/projects

 

f:id:lac_devblog:20210908172438p:plain

 

それでは、OSVが何者なのか分かったところで、実際にOSVに保存されている脆弱性の情報を引いてみましょう。
今回は、opensslの脆弱性を調べてみます。

調べるのはCVE-2021-3711脆弱性です。
SM2の復号時にバッファオーバーフローを引き起こしてしまう脆弱性です。
どのような脆弱性かは下記URLをご参照ください。
https://www.jpcert.or.jp/at/2021/at210036.html
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3711

OSVはWeb APIが公開されているので、以下のようにcurlで情報を取得することができます。

curl -X POST -d '{"version": "1.1.1", "package": {"name": "openssl-src", "ecosystem": "crates.io"}}' "https://api.osv.dev/v1/query"

 

該当するバージョンの脆弱性情報がドコドコ降ってきますが、今回はCVE-2021-3711の情報を見ていきます。

 

f:id:lac_devblog:20210908172642p:plain

curl叩くのダルいよ~」
スマホで見てるんだが~~?」

という方も安心してください。
下記のURLをブラウザで開くだけでも大丈夫です。
同じスキーマ脆弱性の情報が降ってきます。
https://api.osv.dev/v1/vulns/RUSTSEC-2021-0097

では、降ってきたJSONを見ていきましょう。

スキーマの中身の話

下記が、実際に取得した脆弱性の情報になります。

{

    "id": "RUSTSEC-2021-0097",
    "package": {
        "name": "openssl-src",
        "ecosystem": "crates.io",
        "purl": "pkg:cargo/openssl-src"
    },
    "summary": "SM2 Decryption Buffer Overflow",
    "details": "In order to decrypt SM2 encrypted data an application is expected to call the\nAPI function `EVP_PKEY_decrypt()`. Typically an application will call this\nfunction twice. The first time, on entry, the \"out\" parameter can be NULL and,\non exit, the \"outlen\" parameter is populated with the buffer size required to\nhold the decrypted plaintext. The application can then allocate a sufficiently\nsized buffer and call `EVP_PKEY_decrypt()` again, but this time passing a non-NULL\nvalue for the \"out\" parameter.\n\nA bug in the implementation of the SM2 decryption code means that the\ncalculation of the buffer size required to hold the plaintext returned by the\nfirst call to `EVP_PKEY_decrypt()` can be smaller than the actual size required by\nthe second call. This can lead to a buffer overflow when `EVP_PKEY_decrypt()` is\ncalled by the application a second time with a buffer that is too small.\n\nA malicious attacker who is able present SM2 content for decryption to an\napplication could cause attacker chosen data to overflow the buffer by up to a\nmaximum of 62 bytes altering the contents of other data held after the\nbuffer, possibly changing application behaviour or causing the application to\ncrash. The location of the buffer is application dependent but is typically\nheap allocated.",
    "affects": {
        "ranges": [
            {
                "type": "SEMVER",
                "introduced": "0.0.0-0",
                "fixed": "111.16.0"
            }
        ]
    },
    "aliases": [
        "CVE-2021-3711"
    ],
    "modified": "2021-08-24T15:37:57Z",
    "published": "2021-08-24T12:00:00Z",
    "ecosystem_specific": {
        "affects": {
            "functions": ,
            "arch": ,

            "os":
        }
    },
    "database_specific": {
        "informational": null,
        "source": "https://github.com/Shnatsel/advisory-db/blob/osv/crates/RUSTSEC-2021-0097.json",
        "categories": [
            "crypto-failure"
        ],
        "cvss": null
    },
    "references": [
        {
            "type": "PACKAGE",
            "url": "https://crates.io/crates/openssl-src"
        },
        {
            "type": "ADVISORY",
            "url": "https://rustsec.org/advisories/RUSTSEC-2021-0097.html"
        },
        {
            "type": "WEB",
            "url": "https://www.openssl.org/news/secadv/20210824.txt"
        }
    ],
    "affected": [
        {
            "package": {
                "name": "openssl-src",
                "ecosystem": "crates.io",
                "purl": "pkg:cargo/openssl-src"
            },
            "ranges": [
                {
                    "type": "SEMVER",
                    "events": [
                        {
                            "introduced": "0.0.0-0"
                        },
                        {
                            "fixed": "111.16.0"
                        }
                    ]
                }
            ],
            "ecosystem_specific": {
                "affects": {
                    "arch": ,

                    "functions": ,
                    "os":

                }
            },
            "database_specific": {
                "informational": null,
                "categories": [
                    "crypto-failure"
                ],
                "cvss": null,
                "source": "https://github.com/Shnatsel/advisory-db/blob/osv/crates/RUSTSEC-2021-0097.json"
            }
        }
    ]
}

 

1つ1つのフィールドについては、下記のURLに詳細な説明があります。

github.com

 

大まかには、

  • CVE IDと脆弱性が該当するパッケージ名やバージョン情報を紐付け
  • 人間もシステムも使いやすく
  • どんなエコシステムの脆弱性であっても記述できる

という思想に基づいたフィールドが用意されています。

そのため、RUSTSECでの管理IDであるRUSTSEC-2021-0097と、CVE IDであるCVE-2021-3711がaliasesとして紐付けられています。
これにより、脆弱性の影響を受ける・修正が行われたパッケージ名やバージョンの情報と脆弱性の詳細な情報を管理することが可能になります。
今回は存在が認められた脆弱性であるため欠落していますが、withdrawnというフィールドもあり、脆弱性が撤回された場合には、撤回された理由を追記することができます。

まとめ

ということで、Googleが提唱するOSVのスキーマが広く使われるようになり、OSS-Fuzzによって更に多くのOSS脆弱性がスキャンされ続ける日が来ると良いですね。
OSVによって発見されたOSSのCVEを解決するために、日夜OSS活動に励みましょう!!!
他力本願な私は、AIに仕事を奪われてニートになれる日が来ることを、神様仏様Google様に祈り続けておきます。

f:id:lac_devblog:20210908173200p:plain

それでは。