Fix vulnerability in JSON parsing by underhood · Pull Request #9491 · netdata/netdata · GitHub
Skip to content

Fix vulnerability in JSON parsing#9491

Merged
underhood merged 1 commit into
netdata:masterfrom
underhood:buffer_overflow_fix
Jul 7, 2020
Merged

Fix vulnerability in JSON parsing#9491
underhood merged 1 commit into
netdata:masterfrom
underhood:buffer_overflow_fix

Conversation

@underhood

@underhood underhood commented Jul 6, 2020

Copy link
Copy Markdown
Contributor

Summary

If JSON-C is used function:

static inline void json_jsonc_set_string(JSON_ENTRY *e,char *key,const char *value) {
    size_t length = strlen(key);
    e->type = JSON_STRING;
    memcpy(e->name,key,length);
    e->name[length] = 0x00;
    e->data.string = (char *) value;
}

will use memcpy without checking length is less than 256. Reason JSON_NAME_LEN is defined as 256:

typedef struct json_entry {
    JSON_ENTRY_TYPE type;
    char name[JSON_NAME_LEN + 1];
    char fullname[JSON_FULLNAME_LEN + 1];
    union {
        char *string;			// type == JSON_STRING
        long double number;		// type == JSON_NUMBER
        int boolean;			// type == JSON_BOOLEAN
        size_t items;			// type == JSON_ARRAY
    } data;
    size_t pos;					// the position of this item in its parent

    char *original_string;

    void *callback_data;
    int (*callback_function)(struct json_entry *);
} JSON_ENTRY;

By parsing JSON with a key name longer than 256 characters I am able to overwrite memory after with honorable mention being the address of callback_function later in the same struct!

By sending such a JSON trough ACLK I was able to verify that such a key will be parsed by JSON-C and arrive at this function with size_t length = strlen(key); returning 4096! (which is key name length in my crafted JSON dictionary)

Sample from debugger:
Screenshot from 2020-07-06 17-29-16

Screenshot from 2020-07-06 17-51-00

Component Name

Agent JSON switch (code that allows to use of internal JSON and JSON-C parser)

Test Plan

Parsing JSON with key with a name longer than 256 should not create buffer overflow. Example send custom JSON over ACLK link with such key.

Additional Information

@underhood underhood requested review from amoss and mfundul as code owners July 6, 2020 15:18
@squash-labs

squash-labs Bot commented Jul 6, 2020

Copy link
Copy Markdown

@underhood underhood requested review from stelfrag and thiagoftsm July 6, 2020 15:20
@underhood underhood changed the title CRITIACAL: fix vulnerability in JSON parsing fix vulnerability in JSON parsing Jul 6, 2020
@underhood underhood requested review from cakrit, ktsaou and vlvkobal July 6, 2020 15:25
@underhood underhood changed the title fix vulnerability in JSON parsing fixes vulnerability in JSON parsing Jul 6, 2020

@thiagoftsm thiagoftsm left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes are removing any possibility of buffer overflow when this function is called. LGTM!

@underhood underhood merged commit 10e6b74 into netdata:master Jul 7, 2020
@joelhans joelhans changed the title fixes vulnerability in JSON parsing Fix vulnerability in JSON parsing Jul 15, 2020
stormi added a commit to xcp-ng-rpms/netdata that referenced this pull request Jul 16, 2020
stormi added a commit to xcp-ng-rpms/netdata that referenced this pull request Jul 16, 2020
stormi added a commit to xcp-ng-rpms/netdata that referenced this pull request Jul 16, 2020
@underhood underhood deleted the buffer_overflow_fix branch August 26, 2020 13:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants