ICEBlock handled my vulnerability report in the worst possible way
micahflee.com
micahflee.com
Critically, it's not even clear that this is a vulnerability report. Yes the version is out dated, and yes there are known CVEs, but is the server actually vulnerable?
The CVE referenced has the key phrase: "... whose response headers are malicious or exploitable". This does not appear to be a CVE that would impact every installation. You need to find a way to control the response headers, meaning you need to chain another vulnerability.
Without verifying that the server is vulnerable this isn't a vulnerability report. It's a suggestion to install updates. Paired with the poor delivery, it seems reasonable for the author to get blocked and ignored.
I ask this question every time some security guy scans my dependencies, they never can actually determine that and I'm forced to drop everything to fix it.
I prefer establishing an update cadence versus fire drills. Security hygiene over heroics.
Considering how lacking in detail the reports were, I'd probably have just dismissed this man's claims as "AI slop". That he was relying on nmap to tell him the version of something that is easily discovered using openssl s_client (because those HTTP response headers are perfectly human-readable) is kind of telling in and of itself.
It's still a report, which should be handled with seriousness and professionalism. What that app developer did was neither.
I assume this means that the author of this post has seen the Debian version in their nmap. The latest version of which would be 2.4.65-1~deb12u1[1]. You'll notice that there is a Debian version number attached to the Apache version number which means that the version number NMAP found doesn't necessarily mean software is unpatched. I've never used Iceblock or talked to this developer but I have no doubts he's dealing with beg bounties[2], harassment, and bad faith critique of his software which the screenshotted messages look like.
EDIT: For the sake of clarity, I think I should have phrased it the other way around. Bad faith messages look like the ones the author sent. I'm not discussing the actual intention of the messages but the pattern seeking brain's reception to them.
[1]: https://security-tracker.debian.org/tracker/source-package/a...
Sure he should take the vulnerability report seriously, but it's pretty clear that bundling a report above the words "activism theater" isn't going to make someone want to read it.
Instead, just "hey man, you're on a vulnerable version of httpd" is likely going to be more effective.
Finding effective, actionable and safe methods is difficult - but that's the work we have to do.
Conflating a software vulnerability with a criticism of the overall concept is a good way to become non-credible and get both ignored
The article repeatedly claims the entire concept is mere "activism theater" yet with zero evidence or even discussion to back up the claims. In fact, this sort of app may be very effective in both helping people evade authoritarian raids and helping generate flash-mob-type protests that impede the authoritarians. Every bit of friction added to authoritarian rule improves the likelihood of successfully defeating it.
And, buried in the vague overall accusations of not liking the app, the author is stating he's using the wrong version of Apache. I missed anything about the actual good version if it was in there. And, he openly admits he has no idea if the server in question even houses any significant data.
The whole article comes off as the author being an asshat, and even more sore that he's being ignored. TBF, I'd probably ignore him too.
But yeah, it probably is a good idea to run the update sooner rather than later.
Things which take minimal effort but produce a massive response are what Trump's fire hose of duplicitous social media posts are all about. It's perfectly fine work to leverage that same asymmetry in response.
It appear this app was vibe coded, has no security, now serves a lot of people, and the author is somehow thinking how to make money out of it, hence the reluctance to make the code open source
It's pretty clear that the app has its issues (especially wrt to false reports), that I'm not disputing.
No.
“Joshua runs two Bluesky accounts: @iceblock.app, the account of the ICEBlock app, and @joshua.stealingheather.com, Joshua's personal account. His personal account had DMs closed, but the ICEBlock account had DMs open, so [the author] sent him DMs there” about the upcoming blog post.
Joshua reacted to the blog post by blocking the author on the ICEBlock account.
When, “a few days later…[ICEBlock’s] server was still running Apache 2.4.5,” the author “decided to give [Joshua] a deadline to patch his server before [the author] publicly disclosed the vulnerability.” The author sent this deadline to Joshua’s “@joshua.stealingheather.com” account.
“An hour and a half” after the deadline was communicated, Joshua blocked the author from his personal account, too.
Now, the blog post seems to be reasonable criticism to me so I don't think the developer should have blocked him for it. But I don't know, no one has ever written a blog post about me, and I'm not receiving death threats and being threatened by the federal government.
At the end of the day, the author is trying to frame this interaction along the lines of, "Sensitive user data is at risk, and I was blocked for no reason other than for letting the developer know" -- the first part has not been proven to be true, and the second is obviously not true.
The point is the developer didn’t block “the author after seeing them link a blog post.” They received the disclosure and then blocked the author (on that account).
The only serious vulnerability that might have applied would have required the man to be using Apache as a reverse proxy to another server, which is just _extremely unlikely_ considering where it was hosted and what it was being used to do.
The vulnerability couldn’t have been reported in a worse way. OP gave unreasonably short deadlines, allowed moral opinions about the software to interfere with responsible disclosure, and interspersed details about the potential vulnerability with inflamatory remarks about the mission of the product. I don't think OP's goal was actually to secure the app.
OP was going to publish a scathing blog post about ICEBlock either way, and essentially engineered a situation where the ICEBlock author had to act within unreasonable timelines. He published the original blog post an hour and a half after reporting the vulnerability. Then gave a week’s deadline before another one.
Sure, potentially the ICEBlock author also allowed feelings to interfere with upgrading the vulnerable version too.
But ICEBlock has millions of users, according to the blog post. I’m cautious about upgrading dependency versions for apps I manage with <100 internal users. In my experience, upgrades are 99% trivial, and 1% cause disastrous headaches and downtime. If I were the ICEBlock author, I would put this on a list of things to look into, and ensure that it was tested thoroughly if I did decide to upgrade. It’s not as simple as running “sudo apt upgrade”.
And I imagine that given the scale of the product, the author has incredible demands on his time, and can’t just drop everything because somebody (who has already shown themselves to be communicating rather negatively) imposes an arbitrary short deadline.
Now maybe it turns out that I’m unaware that ICEBlock is a huge net negative for the world, which is why this post has so many upvotes. But just interpreting the facts as they’re presented in the article, and substituting ICEBlock for TodoApp… I don’t see how the developer has acted unreasonably.
Post script: I followed up and read the original blog post (https://micahflee.com/unfortunately-the-iceblock-app-is-acti...), which I largely agree with. I still think Micah has mishandled communicating the vulnerability.
My employer rarely has that level of urgency, let alone a side project that is probably revenue negative!
This feels like a hit piece...
Especially when that press doesn’t mention the specific security vulnerabilities you’re reporting to them. Here is a link to the blog post which accompanied the OP’s text: https://micahflee.com/unfortunately-the-iceblock-app-is-acti...
Is it reasonable to expect a maintainer to assume in good faith when the report is this unactionable?
it was in the subsequent one a few weeks later. the first post is erroneous
If you want a different term that's fine, but I don't agree with framing it as all or nothing or the suggested replacement.
If an email asking them to fix it qualifies as coordinated disclosure, then an immediate public post about the bug is also coordinated disclosure. It also brings them in and asks them to take actions.
But the idea of releasing after a fixed delay is fine. That idea should have a name.
We shouldn't imply that releasing after a delay and giving the vendor power over it are the same thing. They should not be lumped together under "coordinated disclosure".
"Coordinated disclosure" very specifically does not mean "giving the vendor power over it".
It should not be what we call "Here's a bug report, by the way I'm posting publicly in 90 days."
If you want to call a disclosure "irresponsible", be prepared to litigate based on the facts of that particular case; there are very few universal ethical rules of disclosure, and those few are only rarely broken in blog posts.
It's not just "imprecise" when the term claims exactly one thing and that thing didn't happen.
If people start referring to any non-immediate disclosure as "coordinated", that causes the same kind of bad effect you were worried about. People get pressured to coordinate because they think most researchers are always coordinating. I don't want that to happen either.
I would never say "irresponsible" just because of timing. You're right that "responsible" is a mess. But "coordinated" if misused also is a mess and also gets coercive.
That you've latched on to a specific opinion about what "coordination" means that excludes that behavior doesn't change how the term works in the security field, what it means, or whether or not it's preferable to "responsible disclosure" to describe that set of actions.
The original objection is only about implications. My hill is similar in size and shape, about implications.
> Coordinated disclosure exists and means what we're describing it to mean: a disclosure where the researcher attempts to reach out to the vendor to remediate prior to publication.
> That you've latched on to a specific opinion about what "coordination" means that excludes that behavior doesn't change how the term works in the security field, what it means, or whether or not it's preferable to "responsible disclosure" to describe that set of actions.
Responsible disclosure also exists and means what we're describing etc.
In practice both terms are treated as basically the same. If we only cared about what already exists and is roughly correct, then both sides of this conversation would be wrong. Both sides are latching onto a specific opinion about what a word means, one side "responsible" the other side "coordinated". So unless you're calling me and tptacek wrong to care, you need a better reason than this.
"Coordinated disclosure" doesn't have any of that. It means "You gave the developer information in advance so that they could prepare/remediate/etc". Which is what it means to coordinate. If I call you up and say "Hey Dylan, I'm going to be at the bar in an hour if you want to grab drinks", I'm coordinating. If I just turn up at the bar and start drinking without contacting you, I am not coordinating.
We don't need to invent another bag of terms for the varying ways that you can respond to my message, because the primary party that matters when we're talking about disclosure methodology is the person releasing the disclosure.
Replace going to the bar with telling me you're going to the grocery store, with no expectation that if I show up you'll talk to me.
90 minutes was how long it took for the issue to be fixed after the deadline expired and the writeup was published.
Arguably this is responsible disclosure deadlines working exactly as intended.
Just like the legendary brown M&Ms, it might be an indicator of worse stuff.
Either don't collect anything useful or at least host the server somewhere where a US warrent doesn't as easily work as cutting butter with a hot knife...
https://developer.apple.com/documentation/usernotifications/...
Maybe I missed it, but was it ever established that these general vulnerabilities are actually relevant to this specific system/implementation?
I can't help but feel that the author's motivation was to get some sort of reaction, and now they've gotten it. If this vulnerability was so vital to be patched, why would it be bundled into a "by the way" DM on Twitter along with a post heavily criticizing the app developer? Both people involved can be idiots here.
Were I building something that I would want to assert the level of privacy claims that ICEBlock asserts, I would absolutely be taking any/all reports about security extremely seriously.
https://micahflee.com/unfortunately-the-iceblock-app-is-acti...
World’s biggest clickbait title backfire?
I do agree with other people’s sentiment here: author is not wrong, but did not really do the most effective thing if their goal was actually to get the ICEBlock author to secure the app. If someone is going to act like a petulant child when confronted with evidence they need to fix something, they need to be treated like a child. And starting off the conversation as combative is going to make the child respond in kind.
I've been burned in the long past when trying to be helpful to an activist. The accuracy of information provided was never a consideration.
Depends on context. When it's a knowledgeable user reporting the issue, you're right.
What I mostly encounter are for profit "security researchers" who try to profit on fear and/or misunderstanding.
Hopefully it doesn't end up doing more harm than good
It’s also not wrong.
The app doesn’t seem designed to do what it claims to do. And the developer doesn’t seem interested in remedying that.
Worse, by hosting this on linode, they may be doing our corrupt DoJ and ICE’s work for them in identifying community organizers who could interfere with them down the road.
If you're running a service that handles sensitive user data and need a third party to tell you how to update your web server, you shouldn't be handling such data at all.
Personal data leaks from apps like this are only going to become more common (especially considering the rising popularity of "vibe coding") unless the people behind them are forced to take responsibility for their lack of security.
But I'm struck that Lee reported CVE-2024-38476 to the author, with a simple link to the NVD site, based on a banner grab.
For those unfamiliar, 2024-38476 is part of a batch of vulnerabilities Orange Tsai announced at Black Hat that year. You can (and very much should) read more about them here:
https://blog.orange.tw/posts/2024-08-confusion-attacks-en/ [†]
This is extremely good (and elegant) vulnerability research. It's also very situational. Lee reports that 38476 "could take over your server". Could it? Did Lee check? 38476 is a second-order vulnerability that pivots CRLF injection in another vulnerable application to an Apache handler override (just read it, it's fucking awesome). If you've got `mod_proxy` enabled, you've got a decent shot at SSRF with it --- SSRF is game-over on a corporate network, but situational when the target is a hobby server. Otherwise, the most likely outcome of it is being able to dump source code (by rewiring the request handling of something from, say, PHP back to HTML). The RCE's on these vulnerabilities are things like "if you were running Redmine, which installs into /usr/share on Ubuntu, you can pull the Rails signing key". Is... that happening here?
Or is this report basically "I did a banner grab, then Googled that version, then made a whole big thing about it to embarrass the author of ICEBlock"?
Which I mean if that's the goal, mazel tov, I don't like these things either, but let's just be clear on what's actually happening here. If not: it would be super interesting to hear a real-world exploitation scenario of Orange Tsai's rewrite bugs against ICEBlock, and Lee should keep on writing.
[†] I wrote about this at the time here: https://news.ycombinator.com/item?id=41199205
2.4.57 never made it into Debian stable, only went as far as testing and unstable.
2023-10-19 was when 2.4.57 was superseded by 2.4.58 in unstable.
So assuming they are not using RHEL or similar, they have either pinned Apache httpd, used a custom build, or haven't updated their server since the start of 2024.
- - -
Since then, there have been 11 moderate, 8 important security fixes according to Apache.
At some point, the fact that this is on Apache 2.Old.Vulnerable is an interesting detail, but I honestly don’t know how you’d make this app secure against the actual threat model here no matter what version of anything you’re running. Dude’s way out past where patching against CVEs is sufficient.