mirror of
https://github.com/louislam/uptime-kuma.git
synced 2026-03-02 22:57:00 -05:00
[Security] Reported via email #863
Labels
No labels
A:accessibility
A:api
A:cert-expiry
A:core
A:dashboard
A:deployment
A:documentation
A:domain expiry
A:incidents
A:maintenance
A:metrics
A:monitor
A:notifications
A:reports
A:settings
A:status-page
A:ui/ux
A:user-management
Stale
ai-slop
blocked
blocked-upstream
bug
cannot-reproduce
dependencies
discussion
duplicate
feature-request
feature-request
good first issue
hacktoberfest
help
help wanted
house keeping
invalid
invalid-format
invalid-format
question
releaseblocker 🚨
security
spam
type:enhance-existing
type:new
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/uptime-kuma#863
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @OmgImAlexis on GitHub (Feb 22, 2022).
⚠️ Please verify that this bug has NOT been raised before.
🛡️ Security Policy
Description
This is to track the issue reported via email. Details can be shared here once the issue has been resolved.
👟 Reproduction steps
See email
👀 Expected behavior
See email
😓 Actual Behavior
See email
🐻 Uptime-Kuma Version
1.11.4
💻 Operating System and Arch
Demo instance
🌐 Browser
Google Chrome
🐋 Docker Version
No response
🟩 NodeJS Version
No response
📝 Relevant log output
No response
@louislam commented on GitHub (Feb 23, 2022):
Thanks, but currently uptime kuma is a single user application, so it is not a issue currently.
@OmgImAlexis commented on GitHub (Feb 23, 2022):
Please reopen this. This IS an issue. I can completely crash the demo instance and even use it to DOS sites. Even as a single user application this is an issue. I find it quite irresponsible to just close this.
@OmgImAlexis commented on GitHub (Feb 23, 2022):
Does this mean I can share the problem on here then since you've deemed it not a security risk? I feel users have a right to know so they themselves can decide the risk factor here.
@hogcycle commented on GitHub (Feb 23, 2022):
send it you wont
@OmgImAlexis commented on GitHub (Feb 23, 2022):
I also noticed a few other issues, I'll send you an email about those too.
@louislam commented on GitHub (Feb 26, 2022):
Thanks!
@OmgImAlexis commented on GitHub (Feb 26, 2022):
@louislam did you not see this comment? I’ll be releasing the details publicly 90 days after the first email as I feel this should be disclosed to users. I believe a CVE should also be issued for this.
@louislam commented on GitHub (Feb 26, 2022):
Yes, I think there are 3 issues, I agree that 1st and 2nd are security issues, but 3rd should be not.
For console.log issue, I may need some time to figure it out where is it, would be appreciated if you could email me where is it.
For DDOS issue, it should be fixed, but it only hurt my demo site.
github.com/louislam/uptime-kuma@595cd93220For input validations, I did mention that the input validations are frontend only currently. (https://github.com/louislam/uptime-kuma/issues/625#issuecomment-939344756) Admin account should not share to other users as always.
In my point of view, since this is a single user application, it should not be a problem. I think no one will try to hack themself.
For example, you send the Windows admin account to other users and then he delete some dll files at C:\Windows and crash the Windows. It does hurt the system, but I think it is not a security issue.
However let say Windows is having a bug that let hackers login the admin account without password and delete some dll files, that is a security issue.
Of course, I am not against this. Ultimately, I strongly agree that server side checking should be implemented. But please understand that I maintain this project with my free time only. Implementing this could be a time consuming task.
EDIT: To be cleared, although I said there is no server side input validation, all those endpoints are still required access token in the current implementation in order to make a request, if you found a endpoint that do not require that is a security issue.
@OmgImAlexis commented on GitHub (Feb 26, 2022):
This issue should be re-opened as it's not resolved.
This shouldn't need me to email you the location. Search the code...
Wasn't fixed at all.
github.com/louislam/uptime-kuma@595cd93220 (r67528328)Good choice in using Windows as an example here as Windows actually prevents exactly this type of thing.
If I leave a windows PC unattended and then someone walks by and tries to delete something in an admin owned directory they're prompted with the UAC. With Uptime kuma if I leave a browser authenticated and walk away this just lets anyone do whatever they want.
I'd also highly suggest you do some research into security. It's not nearly as black and white as you're making it out to be.
@OmgImAlexis commented on GitHub (Feb 26, 2022):
Also this issue should never have been marked as invalid. This is a valid security issue please remove the "invalid" tag and add "security".
@Hypfer commented on GitHub (Feb 26, 2022):
Would you please kindly stop harrassing this open source maintainer.
Your entitled attitude is frankly unbearable.
Security issues are indeed inportant, however what you're forgetting is that you're not talking to some faceless gigacorp here.
Instead, this is a human being who has decided to donate their time working on something for free to the world.
It is completely unacceptable to boss them around like this.
@louislam commented on GitHub (Feb 26, 2022):
Sorry in this case, anyone can steal all your saved passwords in Chrome.
So Chrome is having security issue?
I re-open it for more discussion.
@louislam commented on GitHub (Feb 26, 2022):
Thank you for understanding!
@OmgImAlexis commented on GitHub (Feb 26, 2022):
Not really sure where you got this idea "boss them around like this.".
I never once said they're required todo anything but acting like isn't an issue with 1000s of people use this product isn't the right thing todo.
I even asked nicely.... "please remove"?
@OmgImAlexis commented on GitHub (Feb 26, 2022):
Yes, this is correct. Chrome even made changes to where they store the passwords on disk to reduce the security risk.
@Hypfer commented on GitHub (Feb 26, 2022):
Yes yes. These are all clearly neutral statements showing your support for and your willingness to work with the maintainer.
Definitely no "us vs them" in there.
This is also clearly not in any way threatening the maintainer with public pressure/outcry.
@OmgImAlexis commented on GitHub (Feb 26, 2022):
What in the world are you on about? Have you not heard of responsible disclosure? This is standard practise.
https://en.wikipedia.org/wiki/Coordinated_vulnerability_disclosure
@Hypfer commented on GitHub (Feb 26, 2022):
If that comment existed in a vacuum then maybe yes it could just be a "btw I will be doing responsible disclosure with what I think is a vuln".
That however is not the case. In context, it was clearly perceived as a hostile threat.
@OmgImAlexis commented on GitHub (Feb 26, 2022):
You closed the issue, I asked what was meant to be happening and stated my intention to release a CVE. What part of that is hostile?
@OmgImAlexis commented on GitHub (Feb 26, 2022):
Look, I opened this as a hope to have the issue fixed. Obviously I should have just ignored it and left the repo alone. Sorry.
@Hypfer commented on GitHub (Feb 26, 2022):
I did not close this issue. I'm not the even maintainer. I'm just some maintainer tired of seeing this attitude happen on a regular basis.
Obviously you should've actually tried to help solving the problem if you actually care about that and not just want a CVE with your name on it.
^ This is not how people work together on solving an issue.
@OmgImAlexis commented on GitHub (Feb 26, 2022):
You get I'm ALSO a open source maintainer? I get abuse on a daily basis. If someone opened an issue like this(I've had plenty over the years) I would have worked with them not closed it.
I honestly couldn't give two shits about the CVE number. I DO care about seeing projects like this used by 1000s while there are security issues. 9/10 they're there simply because no one thought to try and break the app. Look at all the things that've been found with libraries just over the last year.
Come on... this is just trying to find something to backup your point.
It was 3AM when I was replying to this, maybe I could have been a little nicer but really no one should need to point out where a console.log is. Open your editor CTRL+F "console.log" oh there it is... you know like how I did...
@OmgImAlexis commented on GitHub (Feb 26, 2022):
Just to make the point obvious. Someone being blunt and stating facts is not the same as someone being hostile. 9/10 this misinterpreted due to a language or culture difference.
Also I do love the fact you've skimmed over that I emailed this to them in the hopes of avoiding needing to publicly state the issue in the hopes it'd be fixed before public disclosure. But ya know... keep going on how I'm hostile, etc. 🙃
@louislam commented on GitHub (Feb 26, 2022):
Thank you all, I think everyone here are trying to help the project.
I am definitely not a security expert here. I always just use my sense and experience to develop something.
Discussions and opinions are welcome. If my knowledge is not correct, feel free to correct me. Also pull requests are welcome too.
@OmgImAlexis commented on GitHub (Feb 26, 2022):
@louislam in that case am I okay to open some PRs this week to add validation and other security fixes? I haven't had a chance to fully audit this app and only had a few glances at the code.
@OmgImAlexis commented on GitHub (Feb 26, 2022):
Neither am I lol I'm just really good at breaking things.
@louislam commented on GitHub (Feb 26, 2022):
I try my best, since I am a bit lazy recently lol. 50+ pull requests are in the queue.
@OmgImAlexis commented on GitHub (Feb 26, 2022):
In that case would a few small focused PRs be better to open than a single big one?
@CommanderStorm commented on GitHub (May 23, 2023):
Please open PRs that are as small as they need to be to achieve the goal.
I.e. multiple PRs, but each with only one distinct addressed issue.
=> This way they stay reviewable + effective.
@CommanderStorm commented on GitHub (May 23, 2023):
@OmgImAlexis Can this issue be closed?