this post was submitted on 10 Jul 2023
3270 points (99.3% liked)
Lemmy.World Announcements
29157 readers
431 users here now
This Community is intended for posts about the Lemmy.world server by the admins.
Follow us for server news π
Outages π₯
https://status.lemmy.world/
For support with issues at Lemmy.world, go to the Lemmy.world Support community.
Support e-mail
Any support requests are best sent to [email protected] e-mail.
Report contact
- DM https://lemmy.world/u/lwreport
- Email [email protected] (PGP Supported)
Donations π
If you would like to make a donation to support the cost of running this platform, please do so at the following donation URLs.
If you can, please use / switch to Ko-Fi, it has the lowest fees for us
Join the team
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
So what happened:
Am I right?
I'm old-school developer/programmer and it seems that web is peace of sheet. Basic security stuff violated:
Am I right? Correct me if I'm wrong.
Again, web is peace of sheet. This would never happen in desktop/server application. Any of the bullet points above would prevent this from happening. Even if the previous bullet point failed to do its job. Am I too naΓ―ve? Maybe.
Marek.
I'm a modern web developer who used to be an old-school one.
Yeah - pretty much, though there are some mitigating factors.
Strictly speaking, it was the alt text for the emoji. Alt text is HTML, and rather than allow arbitrary HTML they allowed another language called Markdown. Markdown is "a plain text" language with human readable syntax specifically designed to be converted into HTML.
Markdown is the right format to use for emoji alt texts, but you do need to be careful of one thing - the original purpose of Markdown was to allow HTML content to be easier to write/read and it is a superset of the HTML language. So arbitrary HTML is valid markdown.
Virtually all modern Markdown parsers disable arbitrary HTML by default, but it's a behaviour which can be changed and that leaves potential for mistakes like this one here. Specifically the way Lemmy injected emojis with alt text into the Markdown content allowed arbitrary HTML.
This wasn't an obvious mistake - the issue over on Lemmy's issue tracker is titled "Possible XSS Attack" because they knew there was an XSS Attack somewhere and they weren't immediately sure if they had found it in the emoji system. Even now reading the diff to fix the vulnerability, it still isn't obvious to me what they did wrong.
It's fairly complex code and complexity is the enemy of security... but sometimes you have to do complex things. Back in the "old-school" days, nobody would have even attempted to write something as complicated as a federated social network...
Yeah - the Lemmy developers made a mistake there. There are a few things they aren't doing right around cookies and JWT tokens.
Hopefully they fix it. I expect they will... It was already actively being discussed before this incident, and those discussions have been seen by a lot more people now.
There are several levels of isolation that could have blocked this:
Yep - the modern best practice is for admins to manage the site via a completely different system. That adds considerable complexity and cost though, so it's rarely done unfortunately. But you know, Lemmy is open source... so if someone wants to take on that work they can do it.
I'll add one more - it should have taken less time to close the exploit... but given this is the first serious exploit I'll forgive that.
Ultimately several of failures contributed to this attack. I expect many of those failures will be corrected in the coming weeks, and that will make Lemmy far more secure than it is right now - so that next time there's a bug like the one in the Markdown parser it isn't able to cause so much disruption.
The good news is no harm was done, and a lot of people are going to learn some valuable lessons as a result of this incident. Ultimately the outcome is a positive one in my opinion.
Awesome write up for someone who doesnβt have much experience at all in coding to understand. Thanks, it was a good read
Oh I forgot another line of defense / basic security mitigation. If a server produces an access token (such as JWT or any other old school cookie / session ID), pair it with an IP address. So in case of cookie theft, the attacker cannot use this cookie from his computer (IP address). If the IP changes (mobile / WiFi / ADSL / whatever), the legitimate user should log-in again, now storing two auth cookies. In case of another IP change, no problemo, one of the stored cookies will work. Of course limit validity of the cookie in time (lets, say, keep it valid only for a day or for a week or so).
I never noticed this. Yes, switch between mobile and WiFi, but this is only two addresses. In case of IPv4 this seems not problem. In case of IPv6, use /64 or /48 (or whatever is now recommended for residential end users) prefix instead of the entire 128bits. I'm not proposing to log-out the suer after IP change, I'm proposing multiple sessions to be accessible at the same time.
Mobile will often switch ip's on tower handoffs. If you're driving down the road or on a train, it's nothing to change mobile ip addresses every 2 minutes.
Not in my experience. But OK, if this is the case, don't use exact IPv4 address, lookup the routing database and use the sub-net. Or whatever. This is belt & suspenders style of defense in depth, just another layer of security if all others fail. Not core functionality.
I work for a mobile game company. Millions of clients. We deal with this a lot. You can't even predict that they'll stay in the same class A. I wouldn't be surprised if they worked out a way to hand off ipv4 to 6 and vice-versa.
Then you have ISP's and large work networks who send everyone out under the same NAT/PAT, 10's of thousands of users all coming from one address.
IMO Providing a public service then trying to identify individuals by network without screwing someone over is a fools errand.
If you're dipping logs and see one jackass doing something on x IP, you always have to go back and see how many ip's that jackass is coming from and also how much viable traffic is coming from that ip.
JavaScript needs access to the cookies, they are the data storage for a given site.
To protect them, the browser silos them to the individual site that created them, that's why developers haven't been able to easily load cross domain content for years, to mitigate XSS attacks.
The security relies on the premise that the only valid source of script is the originating domain.
The flaw here was allowing clients to add arbitrary script that was displayed to others.
You're dead right that only the way to fix this is to do away with JavaScript access to certain things, but it will require a complete refactor of how cookies work.
I haven't done any web dev in a few years, this might even be a solved problem by now and we are just seeing an old school implementation. π€·
Yes, it is called
HttpOnly
and is decided by the server who is sending the cookie to you in HTTP response header. I believe there are also HTTPS-only cookies that when received via HTTPS, cannot be used from HTTP, but I cannot find it right now.Secure
is what you're looking for.You're totally right. I just looked at my old jwt cookie and was susceptible to CSRF (cross site request forgery) by virtue of not having the SameSite flag being set. This has since been fixed, but it looks like there might still be changes pending as Javascript is currently able to read the cookie value (the HttpOnly flag is currently set to false, meaning that it is able to be accessed by the browser). While this isn't a major risk, it does increase the attack surface a bit.
"never happen in a desktop/server application" Just don't run mystery floppys and CDs right :)?
Or rather Electron apps.
If the "special emoji" code contained a script, it could simply read the cookie value and send it to a remote URL by using a XMLHttpRequest. I don't think it has to be decoded to be used.
The web being a PoS? Well, you're certainly right on the money there. Not only that, but it has also become the norm for web technologies to be used in creating desktop applications too.
So we're bringing the security nightmare to desktop applications, and on top of that, it devours RAM like there's no tomorrow, all for the sake of faster development.
To be fair, it's not an issue with "the web." A bug in JavaScript is not a problem for the web. It's a problem for people who use JavaScript.