3 ms·

If you think that's the worst case scenario you're in no position to be making security-related decisions. That line of thinking hinges on a very dangerous assu

If you think that's the worst case scenario you're in no position to be making security-related decisions. That line of thinking hinges on a very dangerous assumption that Ollama doesn't have any critical security vulnerabilities [1]. Don't expose services to the public internet unless they have been battle hardened to be exposed to the public internet, e.g. Nginx as an authenticating reverse proxy. [1] https://github.com/advisories/GHSA-vq2g-prvr-rgr4 https://github.com/advisories/GHSA-vq2g-prvr-rgr4

_flux 1y ago
In general Go programs are quite secure against remote code execution kind class of attacks. Even this one would be remedied by not running ollama as root and not have its binaries owned by the user it is running as (though overwriting executables/libraries that are being mmapped as executables is usually not possible), which I hope would be the standard mode of its setup.
- dns_snek 1y ago
  I don't know why you would say that about Go, you're never more than one programming error away from creating a RCE vulnerability, no matter the language. Linked RCE should demonstrate that quite clearly, don't you think? Either way my point is that software contains vulnerabilities, especially software that hasn't been hardened to be exposed to the public internet. Exposing it to the public internet anyway is a display of bad judgement, doubly so when the person responsible seems to believe that the worst thing that can happen is someone using the software as intended. Details of specific vulnerabilities are really beside the point here. Assuming that the happy path is the worst that can happen is simply naive, there's no two ways about it.
  - _flux 1y ago
    As I understand it, overwhelmingly large majority of CVEs over the history of computing have been due to buffer overflows or use-after-free. If you leave out those vectors, you might actually be pretty close to having RCE-free piece of software. But sure, it's always possible to be more innovative about how to go about enabling RCEs, like the log4j case demonstrates..

_flux 1y ago

In general Go programs are quite secure against remote code execution kind class of attacks. Even this one would be remedied by not running ollama as root and not have its binaries owned by the user it is running as (though overwriting executables/libraries that are being mmapped as executables is usually not possible), which I hope would be the standard mode of its setup.

dns_snek 1y ago
I don't know why you would say that about Go, you're never more than one programming error away from creating a RCE vulnerability, no matter the language. Linked RCE should demonstrate that quite clearly, don't you think? Either way my point is that software contains vulnerabilities, especially software that hasn't been hardened to be exposed to the public internet. Exposing it to the public internet anyway is a display of bad judgement, doubly so when the person responsible seems to believe that the worst thing that can happen is someone using the software as intended. Details of specific vulnerabilities are really beside the point here. Assuming that the happy path is the worst that can happen is simply naive, there's no two ways about it.
- _flux 1y ago
  As I understand it, overwhelmingly large majority of CVEs over the history of computing have been due to buffer overflows or use-after-free. If you leave out those vectors, you might actually be pretty close to having RCE-free piece of software. But sure, it's always possible to be more innovative about how to go about enabling RCEs, like the log4j case demonstrates..