NodeJSのC/C++アドオン拡張機能における脆弱性

著者

Alessio Della Libera

2024年8月14日

0 分で読めます

この調査の主な目的の一つは、NodeJSのnpmパッケージにおけるC/C++の脆弱性を調べることでした。NodeJSのC/C++アドオンを対象に、バッファオーバーフロー、サービス拒否（プロセスのクラッシュ、型チェックの欠如）、メモリリークといった典型的な脆弱性を調査・特定し、関連するソース、シンク、サニタイザーをSnyk Codeでモデル化することに重点を置きます（Snyk brings developer-first AppSec approach to C/C++を参照）。

今回の調査対象は、実装の一部にC/C++インターフェースを使用しているNPMパッケージです。NPMに登録されていないプロジェクトは対象としていません。

このブログ記事では、NodeJSでC/C++アドオンを作成する際に発生しうる、一般的なセキュリティ脆弱性や脆弱なパターンの概要を紹介します。また、オープンソースのメンテナー向けに、修正例や提案も紹介します。

このブログ記事は、Cristian-Alexandru Staicu、Sazzadur Rahaman、Àgnes Kiss、Michael Backesによる論文「Bilingual Problems: Studying the Security Risks Incurred by Native Extensions in Scripting Languages」に着想を得ています。^[1] 原論文では、JavaScriptを含む人気のプログラミング言語におけるネイティブ拡張機能のセキュリティリスクを分析しています。

NodeJSのC/C++アドオンの概要

NodeJSには、ネイティブのC/C++コードを呼び出すためのさまざまなAPIがあります。この調査では、次のいずれかの方法を使用した場合に発生しうるセキュリティ脆弱性を調べます。

node_api.h: Node-API
napi.h: Node-APIのC++ラッパー

上記のライブラリの使用例は、GitHubで確認できます。

アドオンとそのビルド方法について詳しくは、NodeJSの公式ドキュメントを参照してください。

少なくとも1つのパッケージで確認された脆弱性は次のとおりです。

メモリリーク
型チェックの欠如（DoS）
到達可能なassert（DoS）
未処理の例外（DoS）
バッファオーバーフロー
整数オーバーフロー

以下のセクションでは、脆弱なパターンの例と、脆弱性を悪用可能にするために満たす必要がある条件を説明します。

脆弱なパターンの例

このセクションでは、アドオン固有のAPIが適切に処理されない場合にセキュリティ上の問題を引き起こす仕組みと、この調査で特定した脆弱なパターンを見ていきます。

注: 以下の例は、網羅的なリストではありません。このブログ記事で取り上げていないシナリオも、セキュリティ上の問題につながる可能性があります。

このブログ記事では取り上げていないセキュリティ上の問題につながる可能性があります。

セットアップ

node-gypをインストールします（https://github.com/nodejs/node-gyp）。

次のセクションの例を実行するには、以下のファイルを使用します。

package.json

1{
"main": "main.js",
"private": true,
"gypfile": true,
"dependencies": {
  "bindings": "^1.5.0",
  "nan": "^2.18.0",
  "node-addon-api": "^7.0.0"
}
10}

binding.gyp

1{
"targets": [
  {
    "target_name": "test_napi_exceptions",
    "cflags!": [ "-fno-exceptions" ],
    "cflags_cc!": [ "-fno-exceptions" ],
    "sources": [ "test_napi_exceptions.cpp" ],
    "include_dirs": [
      "<!@(node -p \"require('node-addon-api').include\")"
    ],
    'defines': [ 'NAPI_DISABLE_CPP_EXCEPTIONS' ], # if this line is commented, all the tests in test_napi_exceptions.cpp will not crash the process
  },
  {
    "target_name": "test_node_api_assert",
    "sources": [ "test_node_api_assert.c" ]
  },
  {
    "target_name": "test_napi_unchecked_type",
    "cflags!": [ "-fno-exceptions" ],
    "cflags_cc!": [ "-fno-exceptions" ],
    "sources": [ "test_napi_unchecked_type.cpp" ],
    "include_dirs": [
      "<!@(node -p \"require('node-addon-api').include\")"
    ],
    'defines': [ 'NAPI_DISABLE_CPP_EXCEPTIONS' ], # if this line is commented, all the tests in test_napi_unchecked_type.cpp will not crash the process
  },
  {
    "target_name": "test_napi_memory_leak",
    "sources": [ "test_napi_memory_leak.c" ]
  }
]
32}

C/C++拡張機能をビルドするには、次のコマンドを実行します。

node-gyp configure
node-gyp build

特定の例を実行する:

1node main.js <test1|test2|...>

main.js

1const test_napi_exceptions = require('bindings')('test_napi_exceptions');
2const test_node_api_assert = require('bindings')('test_node_api_assert');
3const test_napi_unchecked_type = require('bindings')('test_napi_unchecked_type');
4const test_napi_memory_leak = require('bindings')('test_napi_memory_leak');
5
6function test1(){
7    console.log('[+] Running test1');
8    try {
9        console.log(test_napi_exceptions.test1('foo', 'bar')); // TEST1 - OK
10        console.log(test_napi_exceptions.test1('foo')); // throws an exception
11    } catch (e) {
12        // executed
13        console.log(e); // TypeError: TEST3 - Err1
14    }
15
16    try {
17        test_napi_exceptions.test1(1); 
18        /*
19            FATAL ERROR: Error::ThrowAsJavaScriptException napi_throw
20            ...
21            Aborted
22        */
23    } catch (e) {
24        console.log(e);
25    }
26}
27
28function test2(){
29    console.log('[+] Running test2');
30    try {
31        console.log(test_napi_exceptions.test2('foo', 'bar')); // TEST2 - OK
32
33        console.log(test_napi_exceptions.test2('foo'));
34         /*
35        terminate called after throwing an instance of 'Napi::Error'
36        Aborted
37        */
38
39    } catch (e) {
40        console.log(e);
41    }
42
43}
44
45function test3(){
46    console.log('[+] Running test3');
47    console.log(test_napi_exceptions.test3('foo', 'bar', 'baz')); // TEST3 - OK
48
49    try {
50        console.log(test_napi_exceptions.test3('foo', 'bar')); 
51    } catch (e) {
52        console.log(e); // TypeError: TEST3 - Error2
53    }
54
55    console.log(test_napi_exceptions.test3('foo')); 
56    /*
57        FATAL ERROR: Error::ThrowAsJavaScriptException napi_throw
58        ...
59        Aborted
60    */
61}
62
63function test4(){
64    console.log('[+] Running test4');
65    try {
66        console.log(test_node_api_assert.test1());
67    } catch (e) {
68        console.log(e); // TypeError: Wrong number of arguments
69    }
70
71    try {
72        console.log(test_node_api_assert.test1(1)); // 2
73
74        console.log(test_node_api_assert.test1('1'));
75        /*
76        node: ../test_Assert.c:24: Test1: Assertion `status == napi_ok' failed.
77        Aborted
78        */
79    } catch (e) {
80        console.log(e);
81    }
82}
83
84function test5(){
85    console.log('[+] Running test5');
86
87    console.log(test_napi_unchecked_type.test1('foo')); 
88    // foo
89    // TEST1 - OK
90
91    console.log(test_napi_unchecked_type.test1({'foo': 'bar'})); 
92    // [object Object]
93    // TEST1 - OK
94
95    try {
96        test_napi_unchecked_type.test1({'toString': 'foo'});
97        /*
98        FATAL ERROR: Error::New napi_get_last_error_info
99        ...
100        Aborted
101        */
102    } catch (e) {
103        console.log(e);
104    }
105
106}
107
108function test6(){
109    console.log('[+] Running test6');
110
111    console.log(test_napi_unchecked_type.test2({'foo': 'bar'})); 
112    // bar
113    // TEST2 - OK
114
115    try {
116        test_napi_unchecked_type.test2({'foo': {'toString': 'foo'}});
117        /*
118        FATAL ERROR: Error::New napi_get_last_error_info
119        ...
120        Aborted
121        */
122    } catch (e) {
123        console.log(e);
124    }
125
126}
127
128function test7(){
129    console.log('[+] Running test7');
130
131    console.log(test_napi_unchecked_type.test3(1)); 
132    // 1
133    // TEST3 - OK
134
135    console.log(test_napi_unchecked_type.test3({'foo': 'bar'})); 
136    // nan
137    // TEST3 - OK
138
139    try {
140        test_napi_unchecked_type.test3({'toString': 'foo'});
141        /*
142        FATAL ERROR: Error::New napi_get_last_error_info
143        ...
144        Aborted
145        */
146    } catch (e) {
147        console.log(e);
148    }
149
150}
151
152function test8(){
153    console.log('[+] Running test8');
154    console.log(test_napi_memory_leak.test1(10)); // Xtest1In
155    console.log(test_napi_memory_leak.test1(30)); // Xtest1InitTest14
156
157}
158
159const tests = new Map();
160tests.set('test1', test1);
161tests.set('test2', test2);
162tests.set('test3', test3);
163tests.set('test4', test4);
164tests.set('test5', test5);
165tests.set('test6', test6);
166tests.set('test7', test7);
167tests.set('test8', test8);
168
169function poc() {
170    const args = process.argv.slice(2);
171
172    const t = args[0];
173
174    const test = tests.get(t) || test1;
175    test();
176
177    // never executed
178    console.log('Done');
179}
180
181poc();

未処理の例外

影響: サービス拒否（DoS）

napi

napi APIには、例外を処理し、エラーをスローするためのさまざまな関数があります。ただし、binding.gypファイルで使用するフラグによっては、予期しないクラッシュを避けるために注意が必要です。

たとえば、binding.gypファイルでフラグNAPI_DISABLE_CPP_EXCEPTIONSが設定されている場合、次のシナリオでプロセスがクラッシュする可能性があります（DoS）。

Napi::TypeError::New(env, "").ThrowAsJavaScriptException();など、エラーを生成するほかの関数（たとえば、引数の型が不正な場合）
throw Napi::Error::Newがtry/catchで囲まれていない
同じ関数内で到達可能なreturnのない複数のNapi::TypeError::New(env, "").ThrowAsJavaScriptException();

ドキュメントで説明されているように、「JavaScript例外をスローした後は、必要なクリーンアップを実行したうえで、通常はネイティブコールバックから直ちにreturnする必要があります。」

test_napi_exceptions.cpp

1#include <napi.h>
2
3Napi::Value Test1(const Napi::CallbackInfo& info) {
4    Napi::Env env = info.Env();
5
6    std::string data = info[0].As<Napi::String>().Utf8Value();
7
8    if (info.Length() < 2) {
9        Napi::TypeError::New(env, "TEST1 - Error").ThrowAsJavaScriptException();
10    }
11    return Napi::String::New(env, "TEST1 - OK");
12
13}
14
15Napi::Value Test2(const Napi::CallbackInfo& info) {
16    Napi::Env env = info.Env();
17
18    if (info.Length() < 2) {
19        throw Napi::Error::New(env, "TEST2 - Error");
20        // missing try-catch
21    }
22    return Napi::String::New(env, "TEST2 - OK");
23
24}
25
26Napi::Value Test3(const Napi::CallbackInfo& info) {
27    Napi::Env env = info.Env();
28
29    // multiple reachable ThrowAsJavaScriptException
30    if (info.Length() < 2) {
31        Napi::TypeError::New(env, "TEST3 - Error1").ThrowAsJavaScriptException();
32    }
33
34    if (info.Length() < 3) {
35        Napi::TypeError::New(env, "TEST3 - Error2").ThrowAsJavaScriptException();
36    }
37
38    return Napi::String::New(env, "TEST3 - OK");
39
40}
41
42Napi::Object Init(Napi::Env env, Napi::Object exports) {
43    exports.Set(Napi::String::New(env, "test1"), Napi::Function::New(env, Test1));
44    exports.Set(Napi::String::New(env, "test2"), Napi::Function::New(env, Test2));
45    exports.Set(Napi::String::New(env, "test3"), Napi::Function::New(env, Test3));
46    return exports;
47}
48
49NODE_API_MODULE(addon, Init)

以下の例を実行します。

1node main.js test1
2node main.js test2
3node main.js test3

到達可能なassert

影響: サービス拒否（DoS）

node_api

提供されている例を見ると、一部の例では、関数の戻り値を確認するためにassertが使われていることがわかります。しかし、プログラムの実行中に、汚染された値（JavaScriptコード由来）によってassertに到達すると、クラッシュ（DoS）につながる可能性があります。いくつかのプロジェクトを確認したところ、コードロジック内に到達可能なassertが複数見つかったため、前述のリストに加える価値があると考えました。

このシナリオを修正するには、assertを使う代わりに、if内で戻り値を確認し、プログラムのロジックに応じて適切な値を返す方法が考えられます。

test_node_api_assert.c

1#include <assert.h>
2#include <node_api.h>
3#include <stdlib.h>
4
5static napi_value Test1(napi_env env, napi_callback_info info) {
6    napi_status status;
7
8    size_t argc = 1;
9    napi_value args[1];
10    status = napi_get_cb_info(env, info, &argc, args, NULL, NULL);
11    assert(status == napi_ok);
12
13    if (argc < 1) {
14        napi_throw_type_error(env, NULL, "Wrong number of arguments");
15        return NULL;
16    }
17
18    double value0;
19    status = napi_get_value_double(env, args[0], &value0);
20    assert(status == napi_ok); // if value0 is not double, the assert will fail
21
22    // potential fix
23    // if (status != napi_ok) {
24    //     return NULL;
25    // }
26
27    napi_value sum;
28    status = napi_create_double(env, value0 + value0, &sum);
29    assert(status == napi_ok);
30
31    return sum;
32}
33
34#define DECLARE_NAPI_METHOD(name, func){ name, 0, func, 0, 0, 0, napi_default, 0 }
35
36static napi_value Init(napi_env env, napi_value exports) {
37    napi_status status;
38    napi_property_descriptor desc = DECLARE_NAPI_METHOD("test1", Test1);
39    status = napi_define_properties(env, exports, 1, &desc);
40    assert(status == napi_ok);
41    return exports;
42}
43
44NAPI_MODULE(addon, Init)

この例を実行します。

1node main.js test4

型チェックされていないデータ

影響: サービス拒否（DoS）

napi

napiには、JavaScriptの型を変換するAPIが複数あります。たとえば、

Napi::Value::ToString()は「Napi::ValueをJavaScript文字列に変換して返します」。同様に、Napi::Value::ToNumber()は「Napi::ValueをJavaScriptの数値に変換して返します」。

内部では、napiのNapi::Value::ToString() APIはNode-APIのnapi_coerce_to_stringを呼び出します。

1inline MaybeOrValue<String> Value::ToString() const {
2  napi_value result;
3  napi_status status = napi_coerce_to_string(_env, _value, &result);
4  NAPI_RETURN_OR_THROW_IF_FAILED(
5      _env, status, Napi::String(_env, result), Napi::String);
6}

参照

同様に、napiのNapi::Value::ToNumber() APIは内部でnapi_coerce_to_numberをNode-APIから呼び出します。

1inline MaybeOrValue<Number> Value::ToNumber() const {
2  napi_value result;
3  napi_status status = napi_coerce_to_number(_env, _value, &result);
4  NAPI_RETURN_OR_THROW_IF_FAILED(
5      _env, status, Napi::Number(_env, result), Napi::Number);
6}

参照

napi_coerce_to_stringに関する公式ドキュメントには、次のように記載されています。「このAPIは、ECMAScript言語仕様のセクション7.1.13で定義された抽象操作ToString()を実装します。渡された値がオブジェクトの場合、この関数はJavaScriptコードを実行する可能性があります。」つまり、ユーザー入力でtoStringプロパティが定義されている場合、toString()を呼び出すのではなく、そのプロパティの値が返され、予期しない結果につながる可能性があります。

Napi::Value::ToString()が返した値に対してほかのメソッドを呼び出すと、入力にtoStringプロパティが定義されている場合、例外が発生する可能性があり、多くの場合プロセスのクラッシュにつながります。同じことがnapi_coerce_to_numberにも当てはまります。

脆弱なパターン:

ToString()またはToNumberの結果であるNapi::Valueに対して、適切な型チェックをせずにNapi::String::Utf8Value()などを呼び出す

こうした問題を防ぐには、Napi::Value::ToString()またはNapi::Value::ToNumber()が返す値が、それぞれ文字列または数値であることを確認してから、ほかのメソッドを呼び出します。

注: 前述の未処理の例外と同様に、これらの問題はbinding.gypファイルでフラグNAPI_DISABLE_CPP_EXCEPTIONSが設定されている場合に発生します。

test_napi_unchecked_type.cpp

1#include <napi.h>
2#include <iostream>
3
4Napi::Value Test1(const Napi::CallbackInfo& info) {
5    Napi::Env env = info.Env();
6
7    // possible fix
8    /*
9        if (!info[0].IsString()) {
10            return Napi::String::New(env, "TEST1 - Input is not a string");
11        }
12    */
13
14    std::string data = info[0].As<Napi::String>().ToString().Utf8Value();
15
16    std::cout << data << "\n";
17
18    return Napi::String::New(env, "TEST1 - OK");
19}
20
21Napi::Value Test2(const Napi::CallbackInfo& info) {
22    Napi::Env env = info.Env();
23
24    Napi::Object obj = info[0].As<Napi::Object>();
25
26    std::string data = obj.Get("foo").ToString().Utf8Value();
27
28    std::cout << data << "\n";
29
30    return Napi::String::New(env, "TEST2 - OK");
31}
32
33Napi::Value Test3(const Napi::CallbackInfo& info) {
34    Napi::Env env = info.Env();
35
36    double data = info[0].As<Napi::String>().ToNumber().DoubleValue();
37    std::cout << data << "\n";
38
39    return Napi::String::New(env, "TEST3 - OK");
40}
41
42Napi::Object Init(Napi::Env env, Napi::Object exports) {
43    exports.Set(Napi::String::New(env, "test1"),Napi::Function::New(env, Test1));
44    exports.Set(Napi::String::New(env, "test2"),Napi::Function::New(env, Test2));
45    exports.Set(Napi::String::New(env, "test3"),Napi::Function::New(env, Test3));
46    return exports;
47}
48
49NODE_API_MODULE(addon, Init)

以下の例を実行します。

1node main.js test5
2node main.js test6
3node main.js test7

メモリリーク

影響: 情報漏えい

napi

napi APIには、UTF-8、UTF-16-LE、ISO-8859-1でエンコードされたC文字列からJavaScript文字列値を作成するメソッドが複数あります。これらのAPIは次のとおりです。

これらのメソッドはすべて同じシグネチャを持ちます。

1napi_create_string_*(napi_env env, const char* str, size_t length, napi_value* result)

特に注意して確認すべき値は[in] length、つまり文字列のバイト長です。この値が攻撃者によって制御される場合、またはハードコードされていて入力値が汚染されている場合、resultに予期しないメモリ値が格納される可能性があります。

この問題を避けるには、size_t lengthの値にNAPI_AUTO_LENGTHを使用します。

脆弱なパターン:

const char* strの長さを超えるsize_t lengthを指定してnapi_create_string_*を呼び出す

test_napi_memory_leak.c

1#include <assert.h>
2#include <node_api.h>
3
4napi_value Test1(napi_env env, napi_callback_info info) {
5    napi_status status;
6
7    size_t argc = 1;
8
9    napi_value args[1];
10
11    status = napi_get_cb_info(env, info, &argc, args, NULL, NULL);
12    assert(status == napi_ok);
13
14    int32_t n;
15    status = napi_get_value_int32(env, args[0], &n);
16    assert(status == napi_ok);
17
18    napi_value result;
19
20    // leak n bytes
21
22    status = napi_create_string_utf8(env, "X", n, &result);  
23
24    // status = napi_create_string_utf16(env, u"X", n, &result);
25
26    // status = napi_create_string_latin1(env, "X", n, &result);
27
28    assert(status == napi_ok);
29
30    return result;
31}
32
33#define DECLARE_NAPI_METHOD(name, func){ name, 0, func, 0, 0, 0, napi_default, 0 }
34
35static napi_value Init(napi_env env, napi_value exports) {
36    napi_status status;
37
38    napi_property_descriptor desc[] = {
39        DECLARE_NAPI_METHOD("test1", Test1),
40    };
41
42    status = napi_define_properties(env, exports, sizeof(desc) / sizeof(*desc), desc);
43    assert(status == napi_ok);
44    return exports;
45}
46
47NAPI_MODULE(addon, Init)

この例を実行します。

1node main.js test8

方法

可能な限り多くの問題を自動的にテスト・発見するため、Snyk Codeの機能を活用して以下の方法を取りました。

NodeJSのアドオンAPIを使ってC/C++を呼び出すnpmパッケージのデータセットを作成する
Snyk Codeで、以下をモデル化するセキュリティルールを作成する:
1. ソース: この場合のソースとは、JavaScriptコードに由来する値です。napiではNapi::CallbackInfo::Env()から、node_apiではnapi_get_value_*から取得されるデータなどが該当します。
2. シンク: セキュリティ上の問題に応じて、同じ関数内に複数のThrowAsJavaScriptException呼び出しがあること、assertチェック、文字列値の作成に使われる複数のメソッドなどをモデル化しました。また、メモリリークの問題におけるNAPI_AUTO_LENGTHなど、引数によってコードが脆弱にならない場合も考慮しました。
定義したシンクとソースを使用するルールを作成し、汚染解析を実行してソースからシンクまで汚染を追跡する
既存のサポート対象ルール（たとえばバッファオーバーフローや整数オーバーフロー）で定義されているソースを利用し、NodeJSのアドオンAPIを使用するものだけでなく、さらに多くのC/C++脆弱性をカバーする
作成したルールを、先に構築したデータセットに対して実行する
結果を手動で確認し、必要に応じてPoCを作成する

この方法を使い、NodeJSアドオンに関連するAPIをモデル化してSnyk Codeで分析することで、npmパッケージ内の複数の問題を発見できました。

ただし、発見した問題の一部については、構築したデータセットからいくつかのプロジェクトを抽出し、手動で確認しました。

調査結果

この調査の結果、複数のパッケージで脆弱性が見つかりました。以下に示します。

まとめ

個人的には、いくつかの理由から、この調査は素晴らしい学びの機会となりました。NodeJSアドオンの世界を深く掘り下げ、既存の問題に関する文献を調べ、大規模なリポジトリ群の中から問題を発見するためにSnyk Codeを使ってシナリオをモデル化する機会を得られました。

JavaScriptやほかの多くのプログラミング言語にはかなり慣れていますが、C/C++は最近学び始めた言語です。これは、Snyk Codeのお客様が利用できる複数のセキュリティルールをサポートするために、私たちが取り組んできた（そして今も取り組んでいる）仕事がきっかけです。学びの機会と、Snyk Codeを使って複数のセキュリティ問題をモデル化する機会の両方を得られたこの調査を、とても楽しむことができました。この機会をくださったSnykに感謝します。

NodeJSのC/C++アドオン拡張機能における脆弱性

NodeJSのC/C++アドオンの概要

脆弱なパターンの例

セットアップ

未処理の例外

napi

到達可能なassert

node_api

型チェックされていないデータ

napi

メモリリーク

napi

方法

調査結果

まとめ

参考文献

続きを読む