No supported methods for JSON serialization of trained XGBoost model without using disk

[amohar2]

XGBoost's Learning API for Python provides the following ways to save/load the model:

1. save_config/load_config: this will save/load the internal Booster configuration parameters as JSON. However, it seems that save_config does not save all the required information to load Booster object from scratch. For example, the following code:

`import xgboost
from sklearn.datasets import make_classification

x, y = make_classification(50, 21, 6, n_classes=2)
xtest, ytest = make_classification(10, 21, 6, n_classes=2)
param = {
'eta': 0.3,
'max_depth': 3,
'objective': 'multi:softprob',
'num_class': 3}
dtrain = xgboost.DMatrix(x, label=y)
dtest = xgboost.DMatrix(xtest)
booster = xgboost.train(param, dtrain)
booster.predict(dtest)

saved_config = booster.save_config()

booster = xgboost.Booster()
booster.load_config(saved_config)
booster.predict(dtest)`

will produce the following error:
Traceback (most recent call last):
File "test_xgb.py", line 23, in
booster.predict(dtest)
File "python3.8/site-packages/xgboost/core.py", line 1749, in predict
_check_call(
File "python3.8/site-packages/xgboost/core.py", line 210, in _check_call
raise XGBoostError(py_str(LIB.XGBGetLastError()))
xgboost.core.XGBoostError: [23:39:08] xgboost/src/learner.cc:602: Check failed: mparam.num_feature != 0 (0 vs. 0) : 0 feature is supplied. Are you using raw Booster interface?

2. save_model/load_model: using these two functions, we can save the model from disk and load it back successfully. However, in my particular application, I want to avoid writing the saved model to disk, and save_model() does not provide this option.

3. save_raw/load_model: using save_raw(), we can save the model into a buffer in memory, and load it back with load_model(). It seems that save_raw() always returns a bytes type object that will be used in load_model(). However, similar to pickle, this will create security issues, since malicious code can be executed using bytes type objects.

Are there any other serialize/deserialize functions in XGBoost Learning/Scikit-Learn APIs that address the following requirements:

1. save the model as string or JSON in memory (not bytes/bytearray)
2. can be used to initialize the XGBoost model at a later time

[chyunsu3]

Currently, no, there is no serialization method that meets all your requirements.

[trivialfis]

save the model as string or JSON in memory (not bytes/bytearray)

Is it possible to convert the bytes to string?

[amohar2]

Is it possible to convert the bytes to string?

@trivialfis I can convert bytes output of save_raw() to string, however, load_model() still accepts bytes object, so at some point the saved string needs to converted back to bytes object. So, I think still there will be security concerns, since the users could create their own custom strings and use load_model() to deserialize/execute them

[trivialfis]

since the users could create their own custom strings and use load_model() to deserialize/execute them

Could you please elaborate on this? Specifically how an attacker can use load model to execute anything?

[amohar2]

I cannot come up with a concrete example, however, the output of save_raw() produces the following bytearray:
bytearray(b'binf\x00\x00\x00?\x15\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x05\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0...

My worry is that someone can modify this byte-stream so that arbitrary codes can be loaded, if load_model() is called.
I looked at XGBoosterLoadModelFromBuffer() function in c_api.cc folder, however, I couldn't figure out if this function can load any arbitrary bytestream given to it? If that is not the case, then I can follow your suggestion knowing that there are no security risks with load_model.

[trivialfis]

At the moment this save_raw function is indeed not using JSON format. But it should be trivial for us to make the switch since the JSON format is very well tested by now. Before we were able to switch the default (likely in 1.5), you can try to use virtual memory as file /dev/shm.

I think there might be security risk, we haven't verified things like this yet. I can think of a scenario where someone provides an incorrect node index and somehow XGBoost uses it to read/write the wrong memory location, opening up to some more sophisticated attack methods. Maybe one can try a fuzzer.

[amohar2]

thanks for your suggestion, I agree, using /dev/shm should be a good alternative for now.

[trivialfis]

Closed by #7545 .