It, at the very least, adds additional complexity to exploit your service by putting another layer between attackers and secrets / capabilities held by the application.
And in a case like this, with so many exploitable PHP boxes out there for attackers to choose from instead, certainly buys you some additional protection.
I wouldn’t choose to roll my own on the day I needed it though.
Someone answering “questions for emudhra” also say the keys were intended to be exported to US and EU data centers. I don’t know if that would have precluded inspection (hopefully it’s encrypted some way, but why not have the destination HSM generate the CSR?)
Edit: I see the below paragraph is quoted extensively below. I hadn’t seen those comments yet. Oh well
We have done some preliminary assessment, there appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to Sectigo for cross signing (we verified the files sent over to Sectigo)
The RSA issuers went through a different path as per our assessment of the code and are therefore not impacted.
Some additional context - these issuers created were meant for export to our US and European data centers to solve data sovereignty issues for some of our customers (but never ended up operationally in production except for one).
Wrapping/unwrapping means the HSM would generate the private key and then encrypt it with a key only known to the other HSMs. Those other HSMs would then decrypt the key on import. The private key should still have been impossible to examine outside the HSMs.
Which means there was no way to know they were improperly generated, besides trying to actually bruteforce them, which you wouldn't do because it's usually pointless.
entropy and length might help but it sounds more like duedilligence would be needed. u can have all the solutions in the world. if u dont know how to use them, they are just more problems
Inclusion in the Chrome Root Store requires that a CA Owner continuously demonstrate the technical competence and operational rigor necessary to protect Chrome users. Due to the seriousness of this incident, the Chrome Root Program is conducting a thorough evaluation regarding the status of eMudhra’s remaining CA certificate to ensure these standards continue to be met. We will share further updates as our review progresses.
I bet Entrust never made a cert with a private key of 4.
The problem is the death penalty case is aimed at the wrong target: The entire Web PKI system remains dumb and bad, and the correct answer is to dissolve the CA/B and find people with practical security experience.
Entrust (now Sectigo) is involved with this [0] (cross signed an intermediate) [1] Even last year buying a Sectigo cert got you an Entrust cert with no mention of Sectigo/Comodo[2] (maybe more of a Character.AI situation than a sale)
This is probably a rough definition for "Entrust was banned from being a CA and sold the business off to a competitor". In part, because I also do not think the root programs would just allow Entrust to continue operating the same business under another brand name, unless they are even dumber than I already thought.
Given the amount of progress the CAB forum has led in the last decade+, I'm not sure I agree with that diagnosis. Plenty of people in the forum I can think of who have forced positive changes due to the strength of their experience.
If anyone should be navel-gazing coming out of this incident, surely it's the trust store maintainers. If there's a big concrete improvement to be made, short of burning down the web PKI ecosystem, I'm not sure it's obvious yet.
Does WhatsApp have an obligation to avoid prompt injection on other chat bots?
I don’t think it’s unreasonable for them to include instructions to all chat bots, so that the WhatsApp user on the other end gets the experience they’ve chosen.
It wouldn’t surprise me if the help content including information about regulators makes any chat bots highly likely to suggest contacting the regulators to resolve an issue.
It also seems reasonable for them to want users to actually work with lawyers, instead of chat bots, for legal issues based on the content from their site.
I wonder what apple does when confronted with software that auto-approves the TCC prompt via a VNC connection to localhost.
If there’s some protections that prevent it from happening via localhost, it feels like the next step is to proxy through another host on the LAN.
Heck, I wonder if someone’s already written an app that’ll connect to VNC, look for any permission prompts, and approve. His agent software could just poke it anytime it thinks it’s blocked.
I'd love to see data, but my intuition is that the average developer has access to dramatically better security reviews and far lower cost than ever.
There's more software being written than ever so maybe raw numbers of RCE's could be up, but as a percentage, I'd really expect them to be down. Especially among any fairly common software, as all it takes is anyone working on it to get the idea to test.
What I’m seeing is more developers pushing more code of dubious quality without the ability to respond to feedback on said code.
You can have the best security review in the world, but if the author of the code is not equipped to understand the feedback it ends up being a moot point.
The challenge to me seems less technical and more cultural: how do we keep ourselves intellectually honest and engaged when we now spend the majority of our time orchestrating agents and outsourcing the design and thought processes?
> I'd love to see data, but my intuition is that the average developer has access to dramatically better security reviews and far lower cost than ever.
Where? If I ask Claude to do a “security review” of my software, it gets blocked as a possible hacking attempt.
One issue for developers is that the most powerful models refuse to do comprehensive reviews. You can’t ask Fable 5.1 to find every exploit in your codebase, because that’s indistinguishable from what a bad actor would do.
Sad that this could well be that the path to OpenAI and Anthropic profitability of this arms race between defending LLM white hatting a company’s website and the black hat LLMs attacking it?
So the whole thing is forcing the good guys to outspend on tokens to preemptively defend against the risk of the bad guys outspending them on tokens, rather than buying tokens to actually add features to the product etc.
So are they creating a market for the solution by helping create the problem? A kind of rent-seeking AI security-industrial complex!!
The only thing AI has changed is that it has dropped both: the cost of attack and the cost of defense. Nothing in the game has materially changed; the game has just sped up.
for example the barrier to being a skiddie is basically gone, and low-skill would be hackers can hit very hard.
to develop a CVE into a KEV in 2017 might take 2-3 months with a skilled team of serious security engineers; now my intern can get into police radios without knowing anything about the underlaying technology, essentially on a whim.
any random tier 1 IT drone who can define a VLAN can potentially hit as hard as that team of security engineers now
That is the direct effect of reduced cost. Jevon's paradox type effect: cost goes down demand goes up. You can AI-check so many more things that would be very time consuming earlier.
Assuming an equal level of impact per token spent, the scales have tipped in favour of the attacker.
White hats are constrained by needing to pay for their own tokens, only using (expensive) vendors who meet governance and risk requirements etc. Black hats are free to take over accounts and steal services from wherever they can.
The price has gone up if you’re getting AI to do it. In terms of finding low hanging fruit, reasonably good code scanning tools have been around for a while.
The thing that’s changed for attackers is speed. The things that got you hacked yesterday are the same things getting you hacked today.
Finding and weaponising things like memory corruption bugs required an enormous amount of relatively hard to find skill, and considerable time. An idiot can now throw tokens at the problem and have something they can reliably use within minutes or hours.
The path to vast OpenAI profitability is trivial: advertising. Monetizing several hundred million users = $100+ billion ad network. 900 million active weekly users. Silicon Valley can do ad networks extraordinarily easily. Anybody doubting the ability of OpenAI to build an ad network around GPT will likely be embarassed in the near future.
The path to substantial profitability for Anthropic is questionable. The Chinese LLMs threaten them by far the most of the three major US LLMs. The money for Anthropic is certainly not in $20-$200 subscriptions. And they don't have anywhere near the consumer potential that GPT does, in terms of unleashing an ad spigot. So how far will the API money scale while being undercut by China.
OpenAI has to fight with Google for the ad business, they're specifically building Gemini to focus on consumer + search. Anthropic's business looks cute next to Google's search ad business (which is entirely at risk in this inflection). Meta looks like the biggest potential loser right now, ad dollars will be sucked out of the rotting Facebook network (not Instagram) and redirected to the rapidly expanding, hyper rich context LLM interaction. Advertising on Facebook will feel like running dumb banner ads on Excite in a few years, compared to what GPT will know about its users.
People that think Chinese LLMs are a general threat, don't understand consumer destination services, which is what GPT's future is. China currently has nothing to threaten with in that realm. There is half a trillion dollars of advertising up for grabs.
> Silicon Valley can do ad networks extraordinarily easily.
This is just not true, building an effective advertising platform costs significant amounts of money, time and people.
Remember that you need to hire a sales force for this, and sales scales linearly rather than sub-linearly like engineering.
Additionally, you need to spend a lot of money dealing with fraud, fake and malicious ads.
Furthermore, you need to figure out where to put the ads and how to rank them.
Finally, advertising is a zero sum game (given that the internet has already killed lots of print & OOH advertising), so the only way to win is to better better/cheaper (preferably both) than Google/Meta/Amazon. Best of luck with that (although to be fair to OpenAI they did hire Fidji who knows a lot of this stuff from her time at Facebook).
They don't have a Sheryl Sandberg type figure, and she was also really important in selling FB ads to large advertisers.
Just looking at their leadership team I don't see anyone with a background in (successful) ads companies, so I'm pretty sceptical that they can build this out quickly enough to matter.
Because it's far cheaper to to not spend the tokens finding the vulnerabilities, and software is now being created and released magnitudes faster than ever before. I could see the huge software companies maybe having fewer vulnerabilities, but I expect to see so much more in the smaller side of things.
The surface of potential issues is growing with complexity of all connected parts of the system. That applies to not only software. To prevent issues you either spend proportional amount (dollars, tokens, hours) on testing or reduce complexity of the system.
Because people need to spend time and money on that, which they won’t.
The implementation is cheap, the review and follow-up is not (speaking from a pure LLM only workflow).
My ratio is around 1:2 currently, so twice as much time spent fixing vs building.
> What makes you think RCEs are being found & fixed at a rate that’s faster than they’re being introduced?
It could go either way but we're already at a point where successful exploits in some software (like Chrome) require an absurd amount of exploits to be chained to lead to an actual RCE. We've seen chains requiring more than ten exploits: not kidding.
We'll learn to put more and more sandboxes / guards / checks / defensive techniques everywhere and then all that's going to be needed is for AI looking for security issues to find something ridiculous like 10% of all the actual issues to stop RCEs dead in their tracks.
Also arguably the current SNAFU was expected: we fully knew hardly anyone was taking security seriously.
Now: not so much. Many projects had tens and even hundreds of issues pointed to them.
I think we'll see several things: projects beginning to take security seriously, defense in depth getting generalized and hence RCEs requiring ever more bugs/exploits to be chained to achieve anything, low-hanging fruits getting patched at an insane pace, new code being immediately checked, by LLMs, for not just low-hanging fruits but also more advanced security weaknesses, etc.
We may also see things like the lost art of configuring firewalls making a comeback, the generalization of hardware security modules (where applicable), and even things offering physical guarantees, like time-bounded retrieval protocols, beginning to get used seriously.
If I had to bet I'd say it shall go both ways: some projects are going to extremely sloppy and full of holes but others are going to get so secure nobody shall ever break them.
People didn't store their entire life in the cloud and had every service connected with each other 20 years ago. People pay more attention today, and companies pay a lot more attention today.
Of course, depends heavily on what country you live in.
It's a bad shuffle implementation + using time of day as seed (reducing search space). Using the player's 2 cards and the 3 flop cards, it finds the RNG seed in real time, and then future hands (on the same server) are solved in "under one second!"
After my brief read, one of the main reasons they’re using PCC to produce the signed JPEGs, instead of doing everything on device, is that it maintains your privacy.
If you were signing with the iPhone, an attacker could then correlate photos taken with the same device.
Apple certainly has the data that “this sensor, in this device, took this exact photo” in PCC at the time of signing, but they discard that data.
I’m guessing that’s supposed to be 8th and 17th, or 18th and 27th?
reply