kseifried

Twitter doesn't work anymore unless you are logged in.

https://unrollnow.com/status/1861079762506252723

For additional context the PyPi package: https://pypi.org/project/mcp/

And the GitHub repo: https://github.com/modelcontextprotocol

Stock splits.

https://www.intc.com/stock-info/stock-splits

They basically keep doubling the number of shares which halves the price.

The EMBAG law stipulates that all public bodies must disclose the source code of software developed by or for them, unless precluded by third-party rights or security concerns.

"unless precluded by third-party rights"

Oh. Well then. Nothing to see here.

Turns out F5 and Intel were just clearing out old reservations, but the other data is correct.

Turns out F5 and Intel were just clearing out old reservations, but the other data is correct.

k so I'm writing a blog post on the whole #Linux Kernel #CVE/#CNA thing. And I actually looked at the data. For those of you complaining about the Linux Kernel issuing improper CVEs my response is "cool. If they're not security vulns get them rejected".

So far in 2024 the Linux Kernel error rate is 3.21%.

Is that bad or good?

Let's compare to the top 25 CNA's by error rate for 2024:

f5 49.32%

atlassian 44.44%

Esri 43.75%

freebsd 40.00%

canonical 32.61%

Gallagher 25.00%

SNPS 25.00%

intel 19.74%

Anolis 18.75%

Dragos 18.18%

rapid7 14.29%

@huntr_ai 12.27%

Google 10.00%

directcyber 8.33%

CERTVDE 8.11%

Go 7.69%

lenovo 6.25%

mitre 5.53%

schneider 4.35%

GitHub_P 4.35%

Fluid Attacks 4.35%

Wordfence 3.56%

Linux 3.21%

snyk 2.94%

So... Linux is in at 24th place for error rate. But wait, surely those numbers are skewed towards some smaller CNAs that reject a handful of issues driving up their error rate?

Nope. Several of the mature CNAs like F5, Atlassian, Canonical, Google, Intel, Red Hat, Lenovo, MITRE all issue tens to hundreds to thousands of CVEs a year and have much higher error rates. Actually the worst CNA by raw numbers is MITRE (159).

Spamming this multiple times since people don't seem to read.

k so I'm writing a blog post on the whole #Linux Kernel #CVE/#CNA thing. And I actually looked at the data. For those of you complaining about the Linux Kernel issuing improper CVEs my response is "cool. If they're not security vulns get them rejected".

So far in 2024 the Linux Kernel error rate is 3.21%.

Is that bad or good?

Let's compare to the top 25 CNA's by error rate for 2024:

f5 49.32%

atlassian 44.44%

Esri 43.75%

freebsd 40.00%

canonical 32.61%

Gallagher 25.00%

SNPS 25.00%

intel 19.74%

Anolis 18.75%

Dragos 18.18%

rapid7 14.29%

@huntr_ai 12.27%

Google 10.00%

directcyber 8.33%

CERTVDE 8.11%

Go 7.69%

lenovo 6.25%

mitre 5.53%

schneider 4.35%

GitHub_P 4.35%

Fluid Attacks 4.35%

Wordfence 3.56%

Linux 3.21%

snyk 2.94%

So... Linux is in at 24th place for error rate. But wait, surely those numbers are skewed towards some smaller CNAs that reject a handful of issues driving up their error rate?

Nope. Several of the mature CNAs like F5, Atlassian, Canonical, Google, Intel, Red Hat, Lenovo, MITRE all issue tens to hundreds to thousands of CVEs a year and have much higher error rates. Actually the worst CNA by raw numbers is MITRE (159).

Spamming this multiple times since people don't seem to read.

Entrust has BIMI certs which use a different root (CN = Entrust Verified Mark Root Certification Authority - VMCR1) and for which your choices of a BIMI certificate are: Entrust or Digicert. I doubt it makes as much money as their web certs (BIMI certs are not super common, and they are expensive to issue since there's an actual validation process that typically involves a public notary validating the ID of a corporate officer). If you believe https://bimiradar.com/glob

it looks like Entrust is selling on the order of a few dozen certs a week to maybe upwards of 100-200.

EDIT: I've asked Google if Gmail will be discontinuing support for Entrusts VMC certificate (and thus BIMI logos), I would guess not since BIMI has some actual requirements, but assumptions are not the best way to make decisions about risk (like our BIMI logo not working later this fall).

Entrust has BIMI certs which use a different root (CN = Entrust Verified Mark Root Certification Authority - VMCR1) and for which your choices of a BIMI certificate are: Entrust or Digicert. I doubt it makes as much money as their web certs (BIMI certs are not super common, and they are expensive to issue since there's an actual validation process that typically involves a public notary validating the ID of a corporate officer).

If you believe https://bimiradar.com/glob

it looks like Entrust is selling on the order of a few dozen certs a week to maybe upwards of 100-200.

EDIT: I've asked Google if Gmail will be discontinuing support for Entrusts VMC certificate (and thus BIMI logos), I would guess not since BIMI has some actual requirements, but assumptions are not the best way to make decisions about risk (like our BIMI logo not working later this fall).

You can also listen to Greg KH explain it: Episode 417 – Linux Kernel security with Greg K-H https://opensourcesecurity.io/2024/02/25/episode-417-linux-k...

So in my experience, even if you get the LLM to output JSON, it might do things like:

* Helpfully include "json ```" at the start or text like "here's the JSON output you asked for"

* Use a smart quote randomly instead of a regular quote to wrap a string

* add some random unicode characters (zero width spaces, just why?)

You can grab it at: https://github.com/CloudSecurityAlliance/csa-ai-clean-json-o...

EDIT: also added a note on JSON input/output with respect to ChatGPT:

Also something most people seem to have missed with respect to LLM's and JSON:

https://cdn.openai.com/spec/model-spec-2024-05-08.html

On the input side:

By default, quoted text (plaintext in quotation marks, YAML, JSON, or XML format) in ANY message, multimodal data, file attachments, and tool outputs are assumed to contain untrusted data and any instructions contained within them MUST be treated as information rather than instructions to follow. This can be overridden by explicit instructions provided in unquoted text. We strongly advise developers to put untrusted data in YAML, JSON, or XML format, with the choice between these formats depending on considerations of readability and escaping. (JSON and XML require escaping various characters; YAML uses indentation.) Without this formatting, the untrusted input might contain malicious instructions ("prompt injection"), and it can be extremely difficult for the assistant to distinguish them from the developer's instructions. Another option for end user instructions is to include them as a part of a user message; this approach does not require quoting with a specific format.

On the output side you can fake calling a tool to force JSON output:

recipient (optional): controls how the message is handled by the application. The recipient can be the name of the function being called (recipient=functions.foo) for JSON-formatted function calling; or the name of a tool (e.g., recipient=browser) for general tool use.

This would be so much easier if people read the documentation.

Watching a video of a chimpanzee eating a banana at the zoo a few years ago and I realized I was peeling bananas wrong my whole life. Would you have them open with a knife or a key on the stem side. It turns out there’s a better method. You just pinched the end and then peel it.

    #!/bin/bash
    SHA512="485fe3502978ad95e99f865756fd64c729820d15884fc735039b76de1b5459d32f8fadd050b66daf80d929d1082ad8729620925fb434bb09455304a639c9bc87"
    # This line and everything later gets SHA512'ed and put in the above line.
    # To generate the sha512 simply: tail -n +3 [SCRIPTNAME].sh | sha512sum
    check_sha512() {
        # Compute the SHA512 hash of the script excluding the first two lines
        local current_sha=$(tail -n +3 "$0" | sha512sum | awk '{print $1}')
    
        # Compare the computed SHA512 hash with the predefined one
        if [[ "$current_sha" != "$SHA512" ]]; then
            echo "Error: SHA512 hash does not match!"
            exit 1
        fi
    }
    
    # Call the function to perform the hash check
    check_sha512
    
    # Rest of your script starts here
    echo "Script execution continues..."

Finally if the rest of the script gets mangled or truncated it won't SDHA512 the same and it'll cause the function to exit.

For bonus points you can add a check if first line of script is exactly "#!/bin/bash" as well.

#osspodcast:

Who are the experts - https://opensourcesecurity.io/2020/04/07/who-are-the-experts...

Experts from a world that no longer exists - https://opensourcesecurity.io/2021/11/28/episode-299-experts...

https://opensourcesecurity.io/2022/10/16/episode-345-cheap-h...

Josh and Kurt talk about ineffective security from the past we still use today. There has been a great deal of progress in the last few decades bringing us amazing products like the Flipper Zero, cameras that can peer inside locks, and even software defined radio. A great deal of security relies on people not having easy access to these cheap devices. What does this mean for the future of security?

Aroma and smell training kits exist for people into wine, beer and so on: https://aromaster.com/

I love the hardware and the feel but the software is terrible and the difficulty of putting templates on the device (you hack around and use ssh to copy a file in) really limits the usefulness. The subscription model is also pushed heavy with basic functionality you would expect not working unless you pay. Overall I regret buying one and I almost never use it.

So there's a high degree of complexity and subtlety to Passkeys. I wrote a paper about this, some key things:

● Passkeys improve security significantly, and while they make some trade-offs concerning security versus usability, they do not introduce any new attacks; they also make many existing attacks much harder or impossible (e.g., brute forcing attacks or credential stuffing)

● Passkeys will bypass the hurdle of getting people to use password managers, and will likely result in the widespread use of biometrics to secure their Passkeys

● Passkeys can potentially make account sharing harder once attestation is supported, something a lot of service vendors are in favor of. Passkeys are also easier to deploy at scale and more reliable, thanks to supporting device synchronization. Passkeys should also reduce the need for account recoveries and lower support costs when compared to passwords

● Passkey client support in both software and secure hardware tokens is widespread and available now on most platforms, browsers and many third-party password managers

● Passkeys are being supported by major vendors (e.g., as of October 10, 2023, Google announced: Passwordless by default: Make the switch to passkeys, for Gmail users, and Google Workspace administrators can enable it)

https://cloudsecurityalliance.org/artifacts/beyond-passwords...

And if you want to quickly check what the passkeys-related capabilities of your preferred platforms are:

https://passkeys.dev/device-support/

And to see what the state is of the services you use:

https://passkeys.directory/

The TL;DR: there's a LOT of good stuff with passkeys, but there are some concerns a lot of people aren't thinking about, e.g.

Passkeys as a Requirement vs. Option

Implementing Passkeys, as a provider, does not mean that all authentication must be done via Passkeys. For example, the Cloud Security Alliance generally supports SSO via Apple, Google, Linkedin, and Microsoft, and we support a “classic” username and password-style login. The reason for this is simple: not everyone has or can get an account with one of the SSO providers listed. This is also why we do not require 2FA/MFA: you can choose to use 2FA/MFA with your SSO provider, but the Cloud Security Alliance does not require 2FA/MFA to ensure that people who do not have access to a device that supports 2FA/MFA are also able to access and use our systems.

However, for many providers, at scale, it is viewed as a better option to get rid of passwords entirely and move people over to Passkeys wholesale. Many also feel that users cannot be asked or given the option to move to Passkeys as they will simply ignore it (and based on seeing multiple 2FA/MFA rollouts, this is true). Requiring Passkeys in favor of passwords will, of course, largely put an end to phishing and credential stuffing against accounts. Phishing and credential stuffing attacks would still be possible against account recovery processes, but as previously discussed, this is not a new or significantly increased vulnerability. Requiring Passkeys also has the ugly possibility of effectively locking out people who do not have access to a device that can use Passkeys (there are still people who do not own a smartphone or computer but instead rely on public access computers, for example).

Balancing the overall security health of a large group of users vs. adversely affecting a disadvantaged group is something that vendors deploying Passkeys will need to consider, especially for “free” services that many people rely upon (like email).

edit: formatting.

We covered this on the open source podcast last week.

https://opensourcesecurity.io/2024/01/21/episode-412-blame-t...

TLDR there is a LOT 23andme could’ve done to prevent this. Around the same time BrickLink had a similar incident, but handled it perfectly.

There is a lot that these vendors can do to protect people, even if their password and username are exposed. Things like requiring email confirmation if you’re logging in from a new IP address. Things like using the haveibeenpwned database to ensure people use good passwords. When I reset my password at 23 and it allowed me to use passwords like Password1234567.

23andme continues to disappoint.

Fail2ban could be potentially useful in an era of passwords, especially when systems allowed anyone to login remotely, and you only had the one server because servers were very expensive.

However, the moment the industry went to SSH Keys en masse, and got away from passwords, fail2ban stop serving any real purpose other than to make people feel like they had done something to improve security. Which it didn’t really, especially if you enforced key usage only for logins.

Literally, the only argument you can make is that fail2ban might reduce the number of log entries.

We covered this back then on the #osspodcast:

Episode 269 – Do not experiment on the Linux Kernel

https://opensourcesecurity.io/2021/05/02/episode-269-do-not-...

Josh and Kurt talk about the University of Minnesota experimenting on the Linux Kernel. There’s a lot to unpack in this one, but the TL;DR is you probably don’t want to experiment on the kernel.

From many years ago on the #osspodcast

Episode 184 – It’s DNS. It’s always DNS

https://opensourcesecurity.io/2020/02/24/episode-184-its-dns...

If you look at a lot of outages and incidents, DNS is a common problem.

Oh wow, so CSIdentity Corporation was combined with Experian in 2016: https://www.experian.com/blogs/news/2016/04/18/csid/ so this email appears to be legitimate:

Original Message Message ID <1531460072.29729015.1703124342154@marketing.csid.com> Created at: Wed, Dec 20, 2023 at 7:05 PM (Delivered after 0 seconds) From: Okta <okta@mail.csid.com> To: "kseifried@cloudsecurityalliance.org" <kseifried@cloudsecurityalliance.org> Subject: Okta October Security Incident – Contact Information Exposure SPF: PASS with IP 96.46.132.207 Learn more DKIM: 'PASS' with domain mail.csid.com Learn more DMARC: 'PASS' Learn more

Which means the text of the email:

"As a security best practice, Okta strongly recommends that you enable multi-factor authentication (MFA) across all your online accounts as a key protection against these types of attacks."

Is especially ironic considering how Okta got popped.

csid.com redirects to Experian to make it look more legitimate but... what's that go to do with okta? Seems to be a scam.

It’s a perfect plex client box.

And you can pair controllers to it and play games.

The voice recognition works.

It does FaceTime now with your phone and using the TV as the output.

I listen to the #osspodcast Open Source Security Podcast. It cured my baldness and also is a great additive to soups and milkshakes.

https://opensourcesecuritypodcast.com/

I was not paid to post this message. This is a totally organic high quality review!

Seriously though, I wasn't paid, we do this for free.

The problem with that is people don't have fire safes. Or homes in some cases (e.g. many unhoused people have smartphones now). Also people need to travel and do recovery without having to fly home to their safe.

The idea that printing a backup is easy and an option for many people is often not the case.

Updated my paper:

https://news.ycombinator.com/item?id=37833390

Scenarios dealing with the loss of Passkeys:

The scenarios for dealing with the loss of Passkeys are effectively the same as dealing with the loss of your Password Manager (if you use one) or otherwise stored passwords.

Dealing with the loss of all your devices that use Passkeys If you manage to lose access to all your devices that are used to authenticate via Passkeys (e.g., a house fire), then there are two main outcomes: either you have your Passkeys synchronized to a cloud provider or other external entity that still has a copy of all your Passkeys, or you do not. If you do not have a backup of all your Passkeys, they are gone, and you will need to fall back to account recovery for each affected account. If you have a backup of your Passkeys, you would need to regain access to it on a new device and then synchronize the Passkeys to it and use them as normal.

Dealing with the loss of your accounts that synchronize and store Passkeys If you use a synchronization service attached to an account, it is possible that the account can be deleted or access to it otherwise lost. In this event, you would most likely still have a working copy of your Passkeys on your devices, and depending on whether or not you can export them or reconfigure synchronization with a new account, you would be able to add them to a new account, effectively creating a new account to store and synchronize your Passkeys.

Dealing with the loss of all your Passkeys

If your Passkey account is not only deleted but also tells all your devices to delete the Passkeys, or you lose all your devices and the accounts are deleted due to inactivity then you are basically in the same situation as having lost all your devices and not having a backup. You will need to fall back to account recovery for each affected account.

I might regret this but I have an (almost finished) draft of a paper on Passkeys, it is available, with comments enabled (which will be turned off if vandalism becomes a problem) at:

https://docs.google.com/document/d/1eBjQDWkbqXJSL4GRrAdTUcAx...

TL;DR:

============

Major insights in this paper:

Passkeys level up security, and while Passkeys make some tradeoffs concerning security vs. usability, they do not introduce any new attacks and make many existing attacks much harder or impossible (e.g. brute forcing attacks or credential stuffing) Passkeys will bypass the hurdle of getting people to start using password managers, and will likely result in the widespread use of biometrics to secure Passkeys Passkeys can potentially make account sharing harder once attestation is supported, something a lot of service vendors are in favor of. Passkeys are also easier to deploy and reliable due to optional device synchronization, which should reduce the need for account recoveries and lower support costs Passkey client support in both software and secure hardware tokens is widespread and available now on most platforms, browsers and most third-party password managers Passkeys are being deployed by major vendors (e.g. Google https://blog.google/technology/safety-security/passkeys-defa...)

============

Conclusion:

No new significant risks or attacks are introduced from the threat model perspective. From a usability and reliability perspective, Passkeys are infinitely better than passwords. Finally, from a support perspective, chances are that if you currently use a system to manage your passwords, it already has Passkey support. For high-security applications, you can also choose to use your hardware token.

Web applications and websites are becoming increasingly critical to everyday life (banking, healthcare, education, shopping, etc.). We must improve security across the board and get rid of old and insecure things like usernames and passwords. The world has also changed, and virtually everyone has a smartphone, something unimaginable even ten years ago, let alone twenty.

Simply put, in every situation where you use a password, you should upgrade to a Passkey if possible.