Advisory GHSA-jwvw-v7c5-m82h - Clarification required on ecosystems impacted

[somakdutta]

Hello,

Writing to talk about GHSA-jwvw-v7c5-m82h

For protobuf-java which specifically talks about "protobuf allows remote authenticated attackers to cause a heap-based buffer overflow."

Question : Given the advisory speaks about heap based buffer overflows, how would memory safe languages such as Java be impacted.

Information on this specific vulnerability and how it may affect java ecosystem is quite sparse.

I had reached out on protobuf forums with the same question - you can see further details here https://groups.google.com/g/protobuf/c/vvP4uajRE60/m/wRl8395mBwAJ

Based on the above clarification, would you say it is sufficient information to mark GHSA-jwvw-v7c5-m82h as affecting only C++ ecosystems.

[shelbyc]

Hi @somakdutta,

Thanks for reaching out about GHSA-jwvw-v7c5-m82h! I did some investigation today, and based on what I found, I agree that it's appropriate to remove com.google.protobuf:protobuf-parent from the list of affected products.

Here is what I found:

• This comment says that the issue was fixed by introducing a method called MessageLite::ByteSizeLong().
• I found change notes from version 3.4.0 that say ByteSize() and SpaceUsed() are deprecated.Use ByteSizeLong() and SpaceUsedLong() instead, presumably in reference to this fix.
• When I search for ByteSize in the Protobuf repo, I see that ByteSize() only appears in C++, header, or Python files. Other programming languages
• When I search for ByteSizeLong in the Protobuf repo, I see that ByteSizeLong() only appears in C++ or header files. I can't find any Java files that use ByteSizeLong() - presumably because ByteSizeLong() isn't needed in Java files.
  • Java files appear to use getSerializedSize() instead of ByteSize() or ByteSizeLong().

Additionally, I think I may have identified a fix commit for GHSA-jwvw-v7c5-m82h at protocolbuffers/protobuf@09354db. This commit has a change that sticks out to me:

PROTOBUF_RUNTIME_DEPRECATED("Please use ByteSizeLong() instead")
  int ByteSize() const {
    return internal::ToIntSize(ByteSizeLong());
}

What's less clear to me is whether any products other than com.google.protobuf:protobuf-parent should be removed from the list of affected products in GHSA-jwvw-v7c5-m82h as well. In particular, I think it's possible that Python protobuf uses ByteSize() via a C++ backend, and I'm curious to know under which, if any, circumstances one could use the ByteSize() behavior in C++ to cause issues in the Python protobuf package.

As the response in https://groups.google.com/g/protobuf/c/vvP4uajRE60/m/wRl8395mBwAJ?pli=1 said, it's challenging to find details for CVEs that are ten years old, but I hope what I've found provides some clarity and helps us identify which products should and should not be listed in GHSA-jwvw-v7c5-m82h.

Please feel free to respond and continue the conversation together! I'm interested in hearing input from the community about vulnerability records and how to make them as accurate as possible.

[somakdutta]

Thank you @shelbyc for the response.

For python, i can see there are references to using C++ backend based on an experimental flag in earlier 2.0 versions

PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION which ensures that c++ files are compiled into .so files. And runtime usage follows accordingly.

References
https://github.com/protocolbuffers/protobuf/blob/v2.5.0/python/README.txt#L92
https://github.com/protocolbuffers/protobuf/blob/v2.5.0/python/setup.py#L148

From 3.0 onwards i can see it is inbuilt and no longer behind an experimental flag
https://github.com/protocolbuffers/protobuf/tree/v3.0.0/python#c-implementation
We can see the shared objects present in the python bundle as well here

Quick question : if we have consensus if java should be removed from the ecosystems for this specific vulnerability, what would be the process . Will it require me to raise a pr for review?

[shelbyc]

Hi @somakdutta, I just removed com.google.protobuf:protobuf-parent from the list of affected products. There is no need to create a pull request. In addition, I added this issue thread to the list of references to GHSA-jwvw-v7c5-m82h because I believe our conversation provides valuable details and insights for future readers of the advisory. 🙂