While I think an update to the Apache version is a good idea, this is a very low quality report. There are tons of people scanning the web looking for out-of-date software and sending low effort reports about known CVEs. This is the kind of report even large companies ignore.
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.
>yes there are known CVEs, but is the server actually vulnerable?
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.
That's a good point. I'm a developer and security freelancer so I've been on both sides of that interaction. As a developer I usually update when there's a severe vulnerability in a dependency; checking if I am actually vulnerable would take longer. As a security contractor I've helped teams with some really out of date systems, often with several high severity CVEs. I typically (depending on contract terms) assess if the application is vulnerable, and if so, if there's evidence of compromise.
I prefer establishing an update cadence versus fire drills. Security hygiene over heroics.
Truth. A stripped down configuration of that running nothing but personally-written code on the backend would pretty much render those issues moot (as in "completely mitigated").
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.
> run something like sudo apt update && sudo apt upgrade
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.
It's pretty likely the guy blocked the author after seeing them link a blog post insulting his work, no?
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.
It also barely meets the definition of "a vulnerability report". He basically just nmap scanned the server and googled the apache version. The "critical" vulnerability he linked requires controlling a backend server being reverse proxied through apache... so completely irrelevant. I didn't read every CVE for the apache version but I am doubtful there is anything that actually allows taking over the server there.
Also, Apache 2.4.57 is exactly the version of Apache you get when you'd run RHEL 9 / AlmaLinux / Rocky 9. In that case, the OS would provide backports of the CVE fixes for you and the banner still reads Apache 2.4.57!
That was EXACTLY my first thought on skimming the article. There are commercial vulnerability tools that do this to me repeatedly with Debian and Ubuntu - reporting vulnerabilities in things that the Ubuntu and Debian CVE pages clearly state were patched in backports years prior. Often it is in Apache.
> pretty likely the guy blocked the author after seeing them link a blog post insulting his work, no?
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.
It's pretty clear the developer blocked him from the @iceblock.app account because of the blog post criticizing him, and then blocked him from the other account after he said to not respond but got a page of text back instead. It had nothing to do with the vulnerability report.
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.
> then blocked him from the other account after he said to not respond but got a page of text back
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 "disclosure" was a big waste of time. It was vague and ill-informed, nothing that came after seems to give the impression that they actually knew what they were talking about.
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.
Also, maybe activism theater isn't so bad. I mean not everyone has the temperament or motivation that the severe activists do, and maybe just "doing something" (as long as it's harmless) raises general awareness and critical mass and eventually creates more activism.
It's a nice theory, but that hasn't been borne out in reality. Activision theater allows people to convince themselves that they don't need to do the actual work to protect their communities or disassemble abhorrent systems. It raises the profile of the app developer at the expense of the community.
It is funny, because the amount of people who convinced themselves that they don't need to do the actual work due to activism theater is strictly smaller then amount of people that ... just do not do anything except complaining about activism theater.
Security practices aside, ICEBlock is worse than activism theater; it allows bad actors to intimidate communities with false reports, as it lacks any methods to validate reports and verify users, and was developed without collaboration with the communities it was intended to serve.
I disagree. It's akin to security theatre. People who engage in it can think they've done the right things, when in reality, they might have created more vulnerabilities or now have a false sense of security.
Finding effective, actionable and safe methods is difficult - but that's the work we have to do.
I'd argue making promises of privacy and security that one cannot keep, in enabling civic resistance to unaccountable paramilitary forces, is not harmless.
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.
Oh that app did a huge thing just by showing how far the administration is willing to go with its delusional fascist nonsense. The app was _barely_ functional and available on a minority of the smart phones, and yet there the White House was, making hyperbolic claims on a regular basis about the massive "dangers" it posed. They even went so far as to go after the guy's wife since they didn't have any legal means to oppose him.
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.
Yes, and the fact they responded so strongly shows the app IS definitely effective, and not mere "theater" as the author wants to claim (it may not be as effective as it could be, it might be many things, but it is definitely well above "...sound and fury, signifying nothing").
If you had read the actual article, you'd know that the headline is fitting.
He got warned, that it is an unflattering article, he got the hint with the insecure web server, he had the chance to explain himself and set things right.
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
Disclaimer: UK citizen. I don’t know anything about ICE or whose side I’m “supposed to be on” politically here. I’m just responding to the details in the article. The app might as well be TodoApp.
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.
Yeah he's always been block happy for ANY amount of criticism. Really seems like this guy is more interested in looking like a good person for making this app.
As an individual, blocking people who tax your mental health is healthy. As an app developer, blocking people who try to report security issues is problematic.
There is a difference between blocking people who are disruptive, annoying, etc. And then blocking anyone who doesn't agree with you or levees any amount of criticism of your work. At some point surrounding yourself with only yes men will become unhealthy.
Checking version numbers usually isn’t a good way of determining whether software on Linux is vulnerable to CVEs. Big distros (especially Red Hat derivatives) lock software versions but back port security patches. Reporting “vulnerabilities” solely based on reported version number is pure noise.
This reminding me of pointless PCI scans that flag you for using a vulnerable version of Nginx or a VPN software because that version has a CVE on record. This ignores the fact that the distro version is patched for the non-exploitable CVE.
Oh, one of my absolute favorite things is setting ServerTokens ProductOnly, so that scrubs will freak right out when they see their canned vuln scanner get bug-eyed and basically scream that the server might be vulnerable to every possible exploit ever written.
There's really no such thing as "responsible disclosure", an Orwellian term invented by vendors to create a norm that vendors, and not vulnerability researchers, should set the terms under which vulnerabilities are released. If you need an equivalent term, it's "coordinated disclosure". It's usually best to coordinate disclosure, but not always.
My GOD yes. I spent too much of my life explaining this distinction, not just to vendors, but increasingly to others who think that the vulnerability disclosure model in infosec should be imported to other disciplines (perhaps), but with a little "extra responsibility" (that's not how this was negotiated in infosec, and that's certainly not the way to start exploring the trade-offs in your own area of concern.)
But those aren't the same thing. The basic idea of "responsible disclosure" is that you give the vendor enough time that they could make and deploy a patch. This might involve coordination or it might involve an upfront deadline. "Responsible disclosure" by itself doesn't give the vendor any control. (Unless you're worried about them suing you, but if you're worried about that your whole strategy needs to change far beyond disclosure timing.)
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.
Giving the vendor a deadline up front is coordinating with the vendor. You brought them in on a plan for what you’re going to do and asked them to take actions as part of that plan.
Reporting the bug to the vendor is coordinating in a weak sense, but you're not coordinating the disclosure unless they have input in how the disclosure happens.
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.
There is no basic idea of "responsible disclosure". The term was literally coined so that vendors could call researchers "irresponsible" when they didn't do what the vendors asked. Sometimes immediate disclosure is warranted!
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".
It does have a name. The name is "coordinated disclosure". Coordinated disclosure isn't an absolute good; it often is, and the name is descriptive of the goal.
"Coordinated disclosure" very specifically does not mean "giving the vendor power over it".
This is not an interesting debate. There are two terms in common use. I didn't make either of them up. One is coercive and Orwellian; the other, according to you, is imprecise. I'll live with the imprecision.
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.
You've picked a really weird hill to die on here. 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.
> You've picked a really weird hill to die on here.
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.
The original objection was about branding: the term "responsible disclosure" was specifically coined by entities that wanted to frame involving the vendor prior to disclosure as good, and disclosing immediately to the public as bad. We shouldn't use it, because that framing is incorrct.
"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.
It's not a friendly invite that could turn into doing a thing together. "I'm going to do something you probably don't like in this many days, by myself." is not coordinating. It's too one-sided.
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.
The programmer has been shown to be clueless, well maybe he has a valid reason for using outdated Apache, but to me it smells like... no he doesn't. With that level of professionalism, what other rot is there?
Just like the legendary brown M&Ms, it might be an indicator of worse stuff.
To be fair, even if he did update apache. It's running at linode. One phone call from the feds and they have what want.
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...
The feds, absolutely. Still, there's a lot of other parties that should not have an easy way of accessing the data (if there is any - the joys of closed source implementations).
To have something that is genuinely private and would qualify for listing in the app store, options are pretty limited. I don't think they allow developers to use onion services or anything like that. You could host the server in other countries, but even in hostile countries, it's not a leap of logic to assume the NSA would have an easy time getting in there all without the worry of that pesky "legal" thing.
The author says "it might be trivial for anyone to hack your server." "Might" is doing way too much heavy lifting here. Actually, the author has no idea if there is any actual exploitable vulnerability on the server. They just Googled a version number and fired off a "vulnerability report," which "might" be worth as much as the dozens of emails I get a month about "huge vulnerabilities" related to my SPF record, or those CVEs that boil down to "if someone has root on the machine they could do something bad on the machine."
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.
I don’t think anybody has gone out of their way, even the creator of IceBLOCK himself, to suggest that the creator is an IT security expert. He’s just some guy who accidentally landed in a role and is doing what he can.
I’ve never built something like ICEBlock that puts me personally in the crosshairs of not just normal hacking attempts, but also the political will of the federal government. I can’t imagine the cess pool that is Joshua’s DMs. I think OP makes all the right assessments when examining how seriously ICEBlock is taking the risks here. The Android push notifications assertion is proof enough to make me raise a pretty big question, let alone the other issues raised.
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.
Unless I've got the timeline wrong did the author contact ICEBlock's creator about the outdated Apache version and then a few hours later post publicly about it? If that's the case I can understand why he blocked the author.
Got it, I had to re-read the post a few times before it made sense. I think ICEBlock's creator is definitely a doofus but Micah isn't doing themselves any favors with the way they reported this - more like a "gotcha" than an actual vulnerability disclosure.
Title is pretty inflammatory, I agree, but the article itself is also a pretty savage takedown. It just so happens that it was a pretty reasonable savage takedown backed up by evidence and it’s mostly just excerpts of the ICEBlock app author putting his own foot in his mouth and exposing his rather large lack of knowledge and competence in what he is doing.
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 imagine the ICEBlock author automatically assumed that Micah Lee was some pro-ICE rando without looking into him at all, further proving the blog post title correct.
Yes. As someone who spent years on the receiving end of these, I'd change my original post to be about "real" vulnerabilities, not the results of automated scans.
Unfortunately something like 90% of "vulnerability reports" are some guy in India running an automated scanner reporting something that isn't actually a vulnerability and demanding $1,000+. This creates a ton of noise in the system both for legitimate security researchers and the people stuck managing vulnerability disclosure programs.
Is this guy fishing for a job at DOGE? Otherwise I'm not sure what could explain why he's acting in pretty much the "worst practice" manner possible when doing security reports. Even stuff like the literal teens doing the Burger King (? iirc) and Monster energy reports that got posted here recently, while flawed, were still way better than this.
This very much looks like both people involved are bad actors to each other. ICEBlock seems like a bad and potentially dangerous project led by someone not as competent as they project, despite best intentions, and Micah seems like someone who lept past incident reporting and into bludgeoning with public posts that reveal he's not as competent as he projects, despite best intentions. Hell's paving, etc.
Me having no idea what ICEBlock was thinking that they sent laywers after the author and ignored the warnings. This isn't that but its almost. He seems to genuinely want to help people but doesn't seem to know what he is doing, especially in relation to security.
Hopefully it doesn't end up doing more harm than good
I don’t think the best way to communicate with someone is by questioning their character and intentions, then simply demanding something of them. All this blog post does is show that you need to mature in both your communication style and your security knowledge.
CVE != Vulnerable
The author comes off a bit as a prick there... why didn't he just say "hey man I think you have an issue, it's there, now here's how to fix it (he didn't tell him, he just says in his blog post "it's easy"), and BTW I'm here for a video call if you want me to get through it together"
The title of the original article calling the app "activism theater" is also extremely rude. The author prefered being a prick than doing the best to fix the app.
> title of the original article calling the app "activism theater" is also extremely rude
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.
> now here's how to fix it (he didn't tell him, he just says in his blog post "it's easy")
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.
I'm directionally with Micah Lee on this in that I think all of these kinds of applications are activism theater, and I would hate for anything I say to sound like I'm getting the "ICEBlock" guy's back --- I'm sure it's bad and you shouldn't use it (though: Micah Lee's previous takedown of ICEBlock more or less comes down to "anybody can claim they saw ICE anywhere and also they don't have warrant canaries", which is... not interesting).
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:
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.
Was the author expecting to be praised for submitting multiple false claims? Why do they feel entitled to anything let alone a positive response or action..
No PoC exploit, no real exploitability. I propose we use the term "CVE Kiddie" until this bullshit stops. It could even be a fake-advertised version header.
Assuming Debian because why not, (and because I don't want to look at RHEL):
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.
I am strongly politically aligned with the intention behind ICEBlock, but the app itself has always struck me as the work of someone who is either dangerously underinformed about the practical implications of computer security when pissing off federal paramilitary groups or who is absolutely insane. There might be a way to make something like ICEBlock that isn’t an unintentional honeypot, but the fact that this was on the fucking App Store didn’t give me a lot of hope it was built that way.
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.
> I mean thats also pretty black and white as well, right?
Not really. I'm not making assumptions, just recognizing the behavioral pattern after the fact.
The creator of the app could've just quietly patched the issue and moved on, and we wouldn't be discussing it here. But instead, he clearly chose to assume the worst and immediately go on the offensive, perfectly matching every experience I've ever had of trying to have a good-faith discussion with such activists.
While I think an update to the Apache version is a good idea, this is a very low quality report. There are tons of people scanning the web looking for out-of-date software and sending low effort reports about known CVEs. This is the kind of report even large companies ignore.
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.
>yes there are known CVEs, but is the server actually vulnerable?
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.
That's a good point. I'm a developer and security freelancer so I've been on both sides of that interaction. As a developer I usually update when there's a severe vulnerability in a dependency; checking if I am actually vulnerable would take longer. As a security contractor I've helped teams with some really out of date systems, often with several high severity CVEs. I typically (depending on contract terms) assess if the application is vulnerable, and if so, if there's evidence of compromise.
I prefer establishing an update cadence versus fire drills. Security hygiene over heroics.
> While I think an update to the Apache version is a good idea, this is a very low quality report.
It's still a report, which should be handled with seriousness and professionalism. What that app developer did was neither.
Truth. A stripped down configuration of that running nothing but personally-written code on the backend would pretty much render those issues moot (as in "completely mitigated").
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.
> run something like sudo apt update && sudo apt upgrade
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...
[2]: https://www.troyhunt.com/beg-bounties/
It's pretty likely the guy blocked the author after seeing them link a blog post insulting his work, no?
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.
It also barely meets the definition of "a vulnerability report". He basically just nmap scanned the server and googled the apache version. The "critical" vulnerability he linked requires controlling a backend server being reverse proxied through apache... so completely irrelevant. I didn't read every CVE for the apache version but I am doubtful there is anything that actually allows taking over the server there.
Also, Apache 2.4.57 is exactly the version of Apache you get when you'd run RHEL 9 / AlmaLinux / Rocky 9. In that case, the OS would provide backports of the CVE fixes for you and the banner still reads Apache 2.4.57!
That was EXACTLY my first thought on skimming the article. There are commercial vulnerability tools that do this to me repeatedly with Debian and Ubuntu - reporting vulnerabilities in things that the Ubuntu and Debian CVE pages clearly state were patched in backports years prior. Often it is in Apache.
I need to see ICE Block's SOC 2 Type 1 audit of their processes for patching vulnerabilities along with their latest SOC 2 Type 2 audit.
Their Type 2 attestation would have everything the Type 1 has. I mean obviously you're not being serious but I can't let that one sail by.
Right but the type 2 will prove they actually did what they promised. And yes I’m drawing it out to an absurdity.
> pretty likely the guy blocked the author after seeing them link a blog post insulting his work, no?
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.
It's pretty clear the developer blocked him from the @iceblock.app account because of the blog post criticizing him, and then blocked him from the other account after he said to not respond but got a page of text back instead. It had nothing to do with the vulnerability report.
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.
> then blocked him from the other account after he said to not respond but got a page of text back
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 "disclosure" was a big waste of time. It was vague and ill-informed, nothing that came after seems to give the impression that they actually knew what they were talking about.
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.
So what? The guy probably feels harassed. He doesn’t know the author from Adam.
Also, maybe activism theater isn't so bad. I mean not everyone has the temperament or motivation that the severe activists do, and maybe just "doing something" (as long as it's harmless) raises general awareness and critical mass and eventually creates more activism.
It's a nice theory, but that hasn't been borne out in reality. Activision theater allows people to convince themselves that they don't need to do the actual work to protect their communities or disassemble abhorrent systems. It raises the profile of the app developer at the expense of the community.
It is funny, because the amount of people who convinced themselves that they don't need to do the actual work due to activism theater is strictly smaller then amount of people that ... just do not do anything except complaining about activism theater.
Security practices aside, ICEBlock is worse than activism theater; it allows bad actors to intimidate communities with false reports, as it lacks any methods to validate reports and verify users, and was developed without collaboration with the communities it was intended to serve.
I disagree. It's akin to security theatre. People who engage in it can think they've done the right things, when in reality, they might have created more vulnerabilities or now have a false sense of security.
Finding effective, actionable and safe methods is difficult - but that's the work we have to do.
I'd argue making promises of privacy and security that one cannot keep, in enabling civic resistance to unaccountable paramilitary forces, is not harmless.
THIS.
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.
Oh that app did a huge thing just by showing how far the administration is willing to go with its delusional fascist nonsense. The app was _barely_ functional and available on a minority of the smart phones, and yet there the White House was, making hyperbolic claims on a regular basis about the massive "dangers" it posed. They even went so far as to go after the guy's wife since they didn't have any legal means to oppose him.
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.
Yes, and the fact they responded so strongly shows the app IS definitely effective, and not mere "theater" as the author wants to claim (it may not be as effective as it could be, it might be many things, but it is definitely well above "...sound and fury, signifying nothing").
If you had read the actual article, you'd know that the headline is fitting. He got warned, that it is an unflattering article, he got the hint with the insecure web server, he had the chance to explain himself and set things right.
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
I've read the article. The point I'm getting at is that a vuln report will be taken more seriously if you present yourself in a pleasant manner.
It's pretty clear that the app has its issues (especially wrt to false reports), that I'm not disputing.
Disclaimer: UK citizen. I don’t know anything about ICE or whose side I’m “supposed to be on” politically here. I’m just responding to the details in the article. The app might as well be TodoApp.
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.
This was my immediate reaction as well. 1.5 hours is unreasonably short even for an acknowledgement message!
My employer rarely has that level of urgency, let alone a side project that is probably revenue negative!
This feels like a hit piece...
I've had a negative impression of ICEBlock's developer since GrapheneOS debunked their privacy-related excuses for not creating an Android version: https://bsky.app/profile/grapheneos.org/post/3lt2prfb2vk2r
Yeah he's always been block happy for ANY amount of criticism. Really seems like this guy is more interested in looking like a good person for making this app.
I think this app is probably bad but blocking people is healthy and people who get het up about being blocked are the ones with the problem.
As an individual, blocking people who tax your mental health is healthy. As an app developer, blocking people who try to report security issues is problematic.
Releasing an app doesn't make somebody somehow not an individual.
There is a difference between blocking people who are disruptive, annoying, etc. And then blocking anyone who doesn't agree with you or levees any amount of criticism of your work. At some point surrounding yourself with only yes men will become unhealthy.
No, there clearly isn't.
Sounds about right for a Bluesky user.
These concerns are justified but it is ironic bringing up GrapheneOS which routinely blocks critics as well.
Checking version numbers usually isn’t a good way of determining whether software on Linux is vulnerable to CVEs. Big distros (especially Red Hat derivatives) lock software versions but back port security patches. Reporting “vulnerabilities” solely based on reported version number is pure noise.
This reminding me of pointless PCI scans that flag you for using a vulnerable version of Nginx or a VPN software because that version has a CVE on record. This ignores the fact that the distro version is patched for the non-exploitable CVE.
Oh, one of my absolute favorite things is setting ServerTokens ProductOnly, so that scrubs will freak right out when they see their canned vuln scanner get bug-eyed and basically scream that the server might be vulnerable to every possible exploit ever written.
Giving an author 90 minutes of lead time before public negative press doesn’t count as responsible disclosure.
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?
There's really no such thing as "responsible disclosure", an Orwellian term invented by vendors to create a norm that vendors, and not vulnerability researchers, should set the terms under which vulnerabilities are released. If you need an equivalent term, it's "coordinated disclosure". It's usually best to coordinate disclosure, but not always.
My GOD yes. I spent too much of my life explaining this distinction, not just to vendors, but increasingly to others who think that the vulnerability disclosure model in infosec should be imported to other disciplines (perhaps), but with a little "extra responsibility" (that's not how this was negotiated in infosec, and that's certainly not the way to start exploring the trade-offs in your own area of concern.)
But those aren't the same thing. The basic idea of "responsible disclosure" is that you give the vendor enough time that they could make and deploy a patch. This might involve coordination or it might involve an upfront deadline. "Responsible disclosure" by itself doesn't give the vendor any control. (Unless you're worried about them suing you, but if you're worried about that your whole strategy needs to change far beyond disclosure timing.)
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.
Giving the vendor a deadline up front is coordinating with the vendor. You brought them in on a plan for what you’re going to do and asked them to take actions as part of that plan.
Reporting the bug to the vendor is coordinating in a weak sense, but you're not coordinating the disclosure unless they have input in how the disclosure happens.
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.
Even "responsible disclosure" didn't necessarily give vendors input into "how" the disclosure happened, only "when".
There is no basic idea of "responsible disclosure". The term was literally coined so that vendors could call researchers "irresponsible" when they didn't do what the vendors asked. Sometimes immediate disclosure is warranted!
I get it, you don't like that term.
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".
It does have a name. The name is "coordinated disclosure". Coordinated disclosure isn't an absolute good; it often is, and the name is descriptive of the goal.
"Coordinated disclosure" very specifically does not mean "giving the vendor power over it".
Coordinated disclosure is a terrible term to use when there is no coordination of the disclosure!!
It should not be what we call "Here's a bug report, by the way I'm posting publicly in 90 days."
This is not an interesting debate. There are two terms in common use. I didn't make either of them up. One is coercive and Orwellian; the other, according to you, is imprecise. I'll live with the imprecision.
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.
Let's use neither term in some situations then.
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.
You've picked a really weird hill to die on here. 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.
> You've picked a really weird hill to die on here.
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.
The original objection was about branding: the term "responsible disclosure" was specifically coined by entities that wanted to frame involving the vendor prior to disclosure as good, and disclosing immediately to the public as bad. We shouldn't use it, because that framing is incorrct.
"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.
It's not a friendly invite that could turn into doing a thing together. "I'm going to do something you probably don't like in this many days, by myself." is not coordinating. It's too one-sided.
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.
but that wasn't where he disclosed the vulnerability, right?
it was in the subsequent one a few weeks later. the first post is erroneous
My reading of the article is that they were given a week?
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.
Wait. So Apache is outdated and that’s all you found? And it’s escalated to this? Wow. I would ignore this guy also. Using nmap is an elite skill now?
The programmer has been shown to be clueless, well maybe he has a valid reason for using outdated Apache, but to me it smells like... no he doesn't. With that level of professionalism, what other rot is there?
Just like the legendary brown M&Ms, it might be an indicator of worse stuff.
To be fair, even if he did update apache. It's running at linode. One phone call from the feds and they have what want.
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...
The feds, absolutely. Still, there's a lot of other parties that should not have an easy way of accessing the data (if there is any - the joys of closed source implementations).
To have something that is genuinely private and would qualify for listing in the app store, options are pretty limited. I don't think they allow developers to use onion services or anything like that. You could host the server in other countries, but even in hostile countries, it's not a leap of logic to assume the NSA would have an easy time getting in there all without the worry of that pesky "legal" thing.
Is there a reason why it can't be a PWA?
They can’t do push notifications on iOS.
PWAs could since ios 16.4, released more than 2 years ago
https://developer.apple.com/documentation/usernotifications/...
> outdated software with known vulnerabilities
Maybe I missed it, but was it ever established that these general vulnerabilities are actually relevant to this specific system/implementation?
The author says "it might be trivial for anyone to hack your server." "Might" is doing way too much heavy lifting here. Actually, the author has no idea if there is any actual exploitable vulnerability on the server. They just Googled a version number and fired off a "vulnerability report," which "might" be worth as much as the dozens of emails I get a month about "huge vulnerabilities" related to my SPF record, or those CVEs that boil down to "if someone has root on the machine they could do something bad on the machine."
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.
His arguments against creating an Android version made it seem like he didn't really know what he was doing, when the app first got publicity.
I don’t think anybody has gone out of their way, even the creator of IceBLOCK himself, to suggest that the creator is an IT security expert. He’s just some guy who accidentally landed in a role and is doing what he can.
I wouldn’t call it accidental. No one compelled him to make the app. Anyone can make a similar app
I’ve never built something like ICEBlock that puts me personally in the crosshairs of not just normal hacking attempts, but also the political will of the federal government. I can’t imagine the cess pool that is Joshua’s DMs. I think OP makes all the right assessments when examining how seriously ICEBlock is taking the risks here. The Android push notifications assertion is proof enough to make me raise a pretty big question, let alone the other issues raised.
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.
Unless I've got the timeline wrong did the author contact ICEBlock's creator about the outdated Apache version and then a few hours later post publicly about it? If that's the case I can understand why he blocked the author.
he made the first post about it a few hours after, only gesturing at the potentional. Gave it one week, then posted another spelling it out explicitly
Got it, I had to re-read the post a few times before it made sense. I think ICEBlock's creator is definitely a doofus but Micah isn't doing themselves any favors with the way they reported this - more like a "gotcha" than an actual vulnerability disclosure.
you are mistaken, read the article
Aḷl the information is in the article...
For reference here was his previous article
https://micahflee.com/unfortunately-the-iceblock-app-is-acti...
The title is kinda rude. The content seems pretty fair for the most part.
World’s biggest clickbait title backfire?
Title is pretty inflammatory, I agree, but the article itself is also a pretty savage takedown. It just so happens that it was a pretty reasonable savage takedown backed up by evidence and it’s mostly just excerpts of the ICEBlock app author putting his own foot in his mouth and exposing his rather large lack of knowledge and competence in what he is doing.
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 imagine the ICEBlock author automatically assumed that Micah Lee was some pro-ICE rando without looking into him at all, further proving the blog post title correct.
In the software development / security world, someone reporting a vulnerability to you is one of the greatest things one human can do for another.
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.
> In the software development / security world, someone reporting a vulnerability to you is one of the greatest things one human can do for another.
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.
Yes. As someone who spent years on the receiving end of these, I'd change my original post to be about "real" vulnerabilities, not the results of automated scans.
Unfortunately something like 90% of "vulnerability reports" are some guy in India running an automated scanner reporting something that isn't actually a vulnerability and demanding $1,000+. This creates a ton of noise in the system both for legitimate security researchers and the people stuck managing vulnerability disclosure programs.
Is this guy fishing for a job at DOGE? Otherwise I'm not sure what could explain why he's acting in pretty much the "worst practice" manner possible when doing security reports. Even stuff like the literal teens doing the Burger King (? iirc) and Monster energy reports that got posted here recently, while flawed, were still way better than this.
Am hour and a half isn't enough time to read a DM. Also, the vulnerability would be difficult to exploit.
I think Micah misses the mark here. ICEBlock has vulns, yes, but this was inappropriate.
This very much looks like both people involved are bad actors to each other. ICEBlock seems like a bad and potentially dangerous project led by someone not as competent as they project, despite best intentions, and Micah seems like someone who lept past incident reporting and into bludgeoning with public posts that reveal he's not as competent as he projects, despite best intentions. Hell's paving, etc.
Me having no idea what ICEBlock was thinking that they sent laywers after the author and ignored the warnings. This isn't that but its almost. He seems to genuinely want to help people but doesn't seem to know what he is doing, especially in relation to security.
Hopefully it doesn't end up doing more harm than good
Maybe calling the app "activism theather" was not a very constructive approach.
I don’t think the best way to communicate with someone is by questioning their character and intentions, then simply demanding something of them. All this blog post does is show that you need to mature in both your communication style and your security knowledge. CVE != Vulnerable
The author comes off a bit as a prick there... why didn't he just say "hey man I think you have an issue, it's there, now here's how to fix it (he didn't tell him, he just says in his blog post "it's easy"), and BTW I'm here for a video call if you want me to get through it together"
The title of the original article calling the app "activism theater" is also extremely rude. The author prefered being a prick than doing the best to fix the app.
> title of the original article calling the app "activism theater" is also extremely rude
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.
> now here's how to fix it (he didn't tell him, he just says in his blog post "it's easy")
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.
Perhaps, but there's no need to act like a prick about that
I'm directionally with Micah Lee on this in that I think all of these kinds of applications are activism theater, and I would hate for anything I say to sound like I'm getting the "ICEBlock" guy's back --- I'm sure it's bad and you shouldn't use it (though: Micah Lee's previous takedown of ICEBlock more or less comes down to "anybody can claim they saw ICE anywhere and also they don't have warrant canaries", which is... not interesting).
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
1.5 hours after an email you publish? Seems very bad faith to me
Was the author expecting to be praised for submitting multiple false claims? Why do they feel entitled to anything let alone a positive response or action..
No PoC exploit, no real exploitability. I propose we use the term "CVE Kiddie" until this bullshit stops. It could even be a fake-advertised version header.
Assuming Debian because why not, (and because I don't want to look at RHEL):
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.
The author of this blog post, Micah Lee, has destroyed his reputation.
I am strongly politically aligned with the intention behind ICEBlock, but the app itself has always struck me as the work of someone who is either dangerously underinformed about the practical implications of computer security when pissing off federal paramilitary groups or who is absolutely insane. There might be a way to make something like ICEBlock that isn’t an unintentional honeypot, but the fact that this was on the fucking App Store didn’t give me a lot of hope it was built that way.
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.
Seems like the author is more interested in writing about "activism theater" than anything else.
"Activism Theater" theater
Honestly this seems overly dramatic from both sides
no one looks good here
I tend to agree with the comment on the blog that this version might be patched, and there's no proof of the server being actually vulnerable.
[dead]
[dead]
[flagged]
> To people like him, the world is fully black and white.
followed by
> this is exactly the sort of response I'd expect from a political activist
I mean thats also pretty black and white as well, right?
> I mean thats also pretty black and white as well, right?
Not really. I'm not making assumptions, just recognizing the behavioral pattern after the fact.
The creator of the app could've just quietly patched the issue and moved on, and we wouldn't be discussing it here. But instead, he clearly chose to assume the worst and immediately go on the offensive, perfectly matching every experience I've ever had of trying to have a good-faith discussion with such activists.
[flagged]
[flagged]
Hack it then, micah. Show how l33t you are