google / tsunami-security-scanner-plugins

This project aims to provide a central repository for many useful Tsunami Security Scanner plugins.
Apache License 2.0
860 stars 178 forks source link

AI PRP: Ollama Remote Code Execution Vulnerability #511

Open grandsilva opened 1 week ago

grandsilva commented 1 week ago

According to this research:

Ollama’s HTTP server exposes multiple API endpoints that perform various actions.

This RCE needs to use an arbitrary file write to gain RCE. I'm not sure if this is the preferred method for writing tsunami plugins.

If you're interested in developing a tsunami plugin to detect exposed Ollama HTTP servers, I'll proceed with further research on this case. (however, I think it is one of the most popular open-source GitHub repositories currently, maybe the most popular)

links: https://github.com/ollama/ollama https://www.wiz.io/blog/probllama-ollama-vulnerability-cve-2024-37032

tooryx commented 1 week ago

Hi @grandsilva,

Could you start by writing a fingerprint for ollama to start? If so, could you please create a new issue and I will approve it.

~tooryx

grandsilva commented 1 week ago

Hi @tooryx I'm not sure about the fingerprint as this is an API I guess, Also I'm not interested in writing fingerprints, could you create a PRP for fingerprint so someone else who is interested in writing fingerprints accepts the request?

tooryx commented 1 week ago

Thanks @grandsilva. Anyone that is interested in writing that fingerprint can then create the issue and I will accept it. Feel free to suggest other plugins in the meantime.

~tooryx

maoning commented 5 days ago

@grandsilva Could you start the vuln research, and focus on these 2 areas:

  1. For RCE, what could be an easy way to verify if via arbitrary file write through Tsunami. We may not want to do it all the time, because we don't want Tsunami to do state changing actions. However it is easy to support, we could make it an optional config for users to toggle.
  2. Does the presence of arbitrary file read always indicates the existence of arbitrary file write? If it is the case, we could publish the vulnerability if we can read /etc/passwd file for example.

Please provide timely response, I will monitor this thread. Thanks!

grandsilva commented 5 days ago

@maoning we need to host a docker image, hosing the image is possible with the GitHub container registry. but still, we have a problem here, the hosting should be dynamic because it should contain the callback server address. about the arbitrary file, it is not reflective and we must be able to get the body of requests to our docker registry to read and exploit this vulnerability.

Another option is hosting a docker image with a web server with 4 or 5 endpoints( with Docker Image Manifest V2)

Although, We can send arbitrary get requests to check the exposed API server, but it is unlikely to validate arbitrary file write and file read CVEs with SSRF.