3 ms·
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
by _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 agoI 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 agoAs 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..