I've worked with/for a lot of org over the past few decades, and personal experience proves there are a _lot_ of incidents that go unreported.
The usual is that if there's no logs saying something bad actually happened, there's certainly nothing to say that it did, even though some terribly guessable credentials were used for ages on something publicly exposed. I know, they know, but told in no uncertain terms to drop it.
Nothing to see here, move along. Work to be done, money to be made.
It's hard enough to report issues to OpenAI. Not surprising that information coming out of the company is equally constrained.
Right now my ChatGPT4 history is full of chats I didn't create, on subjects ranging from corporate governance to Roblox scripting to somebody's math homework. It will be only a matter of time before this bug causes them to leak sensitive personal data. I spent 10 minutes looking for a way to report it, but they have successfully insulated themselves from any contact with their (paying) customers.
Pretty annoying, and not something you expect from a supposedly security-savvy company... although that expectation is certainly changing.
Would you be open to collaborating to investigate whether we can further widen this bugged behavior, demonstrate that it's serious, and get it fixed? You could reach me at strangecompanyventure@gmail.com
It sounds like the bug affecting your account is uncommon, making your account special, and as an AI security researcher I can help investigate the extent of the issue and I have contacts that can help call attention to it. Thank you for discovering this and trying to escalate this.
Not at all. OpenAI follows basic accepted standards for security reporting. This is like complaining that you can't find if a website doesn't want specific directories crawled because you don't know about the existence of a robots.txt.
Specifically, OpenAI has a security.txt [0], which is:
> an accepted standard for website security information that allows security researchers to report security vulnerabilities easily [1]
Whenever attempting to find where to report a security issue, the easiest thing to do is always check if the website has a security.txt file.
The email address they have listed there is defunct, and they haven't bothered to update this security.txt page. When you try emailing disclosure@openai.com, you get an auto-reply saying:
Hello and thank you for reaching out to OpenAI. Our vulnerability disclosure program has migrated to OpenAI's bug bounty program, and this mailbox is no longer monitored. Please use the "submit report" functionality available through our bug bounty platform to inform us of security concerns, or reach out to support@openai.com for any non-security-related inquiries.
Thank you for your help in securing OpenAI!
Bug Bounty Program: https://bugcrowd.com/openai
... that was a joke, right? So only people who have heard of the security.txt convention are expected to find this information easily when they need to report a bug?
Under "Reporting security issues" it points you to a bug bounty page: https://bugcrowd.com/openai with a bunch of explanations.
I'm guessing if you also just send an email to security@openai.com it'll go to someone. Using Bugcrowd just seems like a nice way to also run a bug bounty as part of their normal intake.
OpenAI seems to have, unfortunately, outsourced the triaging of bug bounty reports to people who don't seem to understand security well enough to recognize issues. As an example, I've been trying to get OpenAI to fix the fact that "eval()" is used incorrectly in one of their Cookbooks in a place where the correct function would be "json.loads()".
The bug bounty report was closed with a message saying:
Upon reviewing your report and consulting with the OpenAI team, we have determined that this feature is operating as intended. This means it does not constitute a valid sandbox escape. The Code Interpreter environment is securely sandboxed to support code writing and execution, including shell operations. Any code execution within this environment falls outside the scope of our program ... As you have not demonstrated a valid sandbox escape or RCE, we're closing this submission as Not Applicable.
This shows a fundamental misunderstanding of basic coding, as the eval() I pointed them to is completely unrelated to the Code Interpreter environment. So, the report is incorrectly considered "Not Applicable", without any real further ways to try to get them to fix it. I tried contacting the Cookbook authors directly, but never heard back.
I can't be arsed to create an account on a third party 'bug bounty' site, or to waste time guessing email addresses, or to download a security.txt file I've never heard of. Sorry. Their loss, not mine. If they make it hard for me to help them, they can't be too surprised when I give up trying.
Ya I hope people are not putting any sensitive information when using Chat GPT. Anything that can get stolen will get stolen. Just a matter of when not if. On device LLMs with no network transmissions are the only way to keep things safe if you really care.
> Ya I hope people are not putting any sensitive information when using Chat GPT.
The ship has sailed, OpenAI wants you to put everything in their system. It makes them more valuable. They know there is no repercussions because their base will blindly advocate for them regardless under the guise of “the best llm”.
Post headline has been editorialised yet still terrible clickbait.
> OpenAI’s internal messaging systems early last year, stealing details of how OpenAI's technologies work from employees. Although the hacker did not access the systems housing key AI technologies, […]
Enough said. It’s completely normal to not disclose a breach if there’s no proof or great likelihood that customers were implicated.
A poorly written article regurgitating the NYT story with uninformed alarmist shitty podcast tier ‘analysis’.
Sounds like they got access to email and Slack; that’s the gateway to a lot of other things. Fact is, OpenAI was booming at the time of this hack and they had every incentive to play down the severity internally. The hackers may not have gotten access to the “systems housing key technologies”, ie no SSH access to the production VMs (although I’m not sure I would trust that OpenAI’s auditing of such access was foolproof) but that doesn’t mean they couldn’t have done a lot of other damage, gathered all sorts of source code and secrets, or put a backdoor in somewhere. All in all, given the claims they are making and the level of trust they demand from their customers, they ought to have been far more open at the time.
> It’s completely normal to not disclose a breach if there’s no proof or great likelihood that customers were implicated.
A bit more complicated than that for public companies. But OpenAI is private, so yeah, they most likely don't have to. It's still an interesting scoop for a journalist, though.
Do not waste your energy thinking that companies like this will be “consistently candid”. That’s not what they’re here for, and it’s clear from other events in their history that they have no interest in this.
> OpenAI's systems, where the company keeps its training data, algorithms, results, and customer data, were not compromised
Article just rambles about some unnamed uninformed AI-phobes being concerned about US national security in relation to China because of some unknown OpenAI internal information that might have leaked.
The usual is that if there's no logs saying something bad actually happened, there's certainly nothing to say that it did, even though some terribly guessable credentials were used for ages on something publicly exposed. I know, they know, but told in no uncertain terms to drop it.
Nothing to see here, move along. Work to be done, money to be made.