Is the llama.cpp webui in danger from the recent npm attack?
Posted by shroddy@reddit | LocalLLaMA | View on Reddit | 11 comments
There is a new npm attack with over 400 compromised packages, and the llama.cpp webui uses npm and many packages and their dependencies which in turn has their own dependencies. Is it known if any of them are compromised as well, or does it pin all packages and dependencies down to their minor version number thoroughly enough?
Diligent-Pepper5166@reddit
https://www.prismor.dev/blog#attack-of-shai-hulud
Read this
AppearanceHeavy6724@reddit
AFAIK llama.cpp uses static pages, does not run any npm neither during build no during execution.
aldegr@reddit
There is an NPM build process, but contributors are expected to build it and include the build artifacts in their PRs. So if you’re building llama.cpp, there is no need to build the webui because it is committed in the repo.
There is a draft PR to automatically build the webui (with npm) in CI if a change requires it.
@shroddy is getting downvoted, but is correct that the webui requires an npm install/build. It’s just done for you.
shroddy@reddit (OP)
During normal build, is does not build the webapp, but when building the webapp, it requires to use npm install.
MelodicRecognition7@reddit
what is "webapp"?
llama-serverdid not require anynpm installas of build b6999 from 10 November which already had the new SvelteKit Web UIshroddy@reddit (OP)
Yes, but if you want to edit the web app, you need npm install. Of course if you are masochistic enough you can edit the minified version...
Icy_Bid6597@reddit
Regarding your question: they do not pin particular versions. In package.json all of entries starts with \^ ie. \^11.11.1. That means that NPM can choose newer minor version.
In JS enviroment there is also package-lock.json that pinpoints versions that were used during development. Until someone will refresh it all versions stay the same.
So it is mostly fine,
But what is important is to understand the risk of the NPM attack. It is mostly targeted towards dev machines / CI infrastrructure. These attack MAY allow a malicious person to perform RCE on someone else machine WHEN the package is used.
Normally you build some code, execute your build manager that produce final artifacts. During the build process some of the libraries may access your disk, execute commands or try to do any other actions.
After build process the result is a set of static html/js files. These DOES NOT HAVE access to your machine. They live only in the browser.
There is still a chance that someone will include code that will be executed in your browser, but the potential risk is minimal. There is no direct access to disk, no easy way to execute shell comands. Browsers are pretty safe.
The worst thing that could happen is maybe keylogging what are you doing in this particular tab and sending it somewhere else. Or allow someone to perform an XSS attack on your website (which is not a case in lama.cpp situation).
Since the official releases of lama.cpp have webui already built, there is really no real risk.
shroddy@reddit (OP)
So in this case, packages-lock.json was last edited 19 November in the git repo, with 3 updated packages. The build instructions say npm install, does that update the lock file? I hope my questions aren't too annoying but I really like to know how close llama.cpp or the developer of the web UI or anyone who used npm install with the web UI (thankfully not me) was to a real catastrophe.
SlowFail2433@reddit
This is not rly the sort of library you want to use in high security situations. Ideally for high security setup you would want to go via CUDA kernel, compile down ahead of time to PTX and then compile that down ahead of time to streaming assembly (SASS). Then the streaming assembly code has extremely limited ability to be malicious. Personally I only ever deploy SASS.
AppearanceHeavy6724@reddit
npm is for the web frontend, duh, not the tranformer compute part.
SlowFail2433@reddit
Yes the javascript part is not actually doing the matrix multiplications, but from a security audit perspective does that distinction matter? It’s still running on the same bare metal server interacting with the data flow. Like in general the standard is that npm doesn’t get allowed onto highly secure servers in general.