The Security WG has a recurring virtual meeting once every four weeks. Meeting minutes and the time and date of the next meeting will be published in this thread.
Meetings are open to EEF members: the meeting link is published to the #security channel on EEF Slack one hour prior to each meeting.
3 Likes
Participants: Holden Oullette, @maennchen , @max-au , Paul Swartz, @peerst , @voltone
Ongoing (Holden)
Try to add to automated test suite for web servers
Code review of three handlers (HTTP 2.0, HTTP 1.1 and Websocket)
Needs some preparation, to avoid locking out users without 2FA
Send out email, and heads-up in Slack (@max-au )
See Whitehouse paper on memory safe languages
Counter FUD
Collaborate on a doc, targeting blog post or white paper
To be shared with Marketing WG for distribution
EU funded project (@peerst )
SBoM tooling upgrades
Should be publish to Erlang Forums
2nd May 2024 at 16:00 CEST / 14:00 GMT / 10am EDT / 7am PDT / 23:00 JST
5 Likes
Small Correction: it’s FAPI 2.0.
Spec: FAPI 2.0 Security Profile
2 Likes
max-au
April 17, 2024, 2:59am
4
voltone:
GitHub org 2FA
This is now enforced, all erlef repo members must have 2FA enabled. Please ping me or infra@ if you are accidentally locked out.
3 Likes
(Oops, sorry: previous notes erroneously said the next meeting would be on May 2nd)
Participants: @maennchen , @max-au , Paul Swartz, @varnerac , @voltone
Implementation done
Conformance test passed
Stipend requested for certification
Checking to see if EEF can apply for funding
Considering submitting a proposal around SCITT
Question: is it not too early, considering work on the spec is still in progress?
Reminder: supply chain work should also consider Erlang/OTP itself
Several vulnerabilities in commonly used packages
Disclosure planned for mid-May
Role for EEF SecWG?
After disclosure, review how community handled it
Check if there is a need to improve processes, tooling, etc.
Lots of outdated issues and PRs
Have a look in coming weeks
Review status during next call
Stipend is ready
Hex team is positive about the proposal
Check with Holden about someone who might pick up the work
Informal proposal discussed with Hex team
Automatically retire packages with known vulnerabilities
Question: are “retired” and “mentioned in a vulnerability report” not two orthogonal things?
Revisit after “Trusted Publishers” collaboration with Hex team
Wed 29 May 2024 at 16:00 CEST / 14:00 GMT / 10am EDT / 7am PDT / 23:00 JST
5 Likes
Participants: @maennchen , @max-au , Paul Swartz, @ingela , @rickard , @voltone
Background: The Marvin Attack
OTP 27 deprecates asymmetrical encryption/decryption functions in crypto and public_key
RSA key exchange, which uses these functions, was already disabled by default due to the ROBOT attack ; it is now actively discouraged
Fixing or deprecating these functions was pushed for by the researchers behind the Marvin attack
Practically not possible for OTP team to guarantee these functions are safe, as it depends on libcrypto dependency
No plans to remove these functions, likely to stick around for quite a while
At least until RSA key exchange, as a compatibility option, is completely removed
If/when there is a plan for removal, it will be announced well in advance
Could other use-cases, in 3rd party apps/libraries, be safe?
Depends on the threat model: can an attacker attempt many decryptions and measure the runtime?
What alternative do authors have? Adding custom libcrypto bindings adds complexity and could introduce new vulnerabilities
Plan: improve documentation, warn about risks, explain what plans OTP team have with these functions
Wed 26 June 2024 at 16:00 CEST / 14:00 GMT / 10am EDT / 7am PDT / 23:00 JST
6 Likes
Participants: @maennchen , @peerst , @varnerac , Alistair Woodman, Michael Lubas, @voltone
Funding for FAPI certification approved
Feedback incorporated, ready for release
Reach out to Marketing WG for visibility
Deadline has passed
Similar opportunities likely to pop up, consider submitting
Privately disclosed to some projects
No public statements or fixes seen yet
Stalled, need someone who can do the work
Bunch of consultations scheduled ; would be good if some of us could attend at least some of them
Chronological list in our Slack channel, for convenience; first five already happened
Registration (using the above link) required
@maennchen and @voltone will try to register, attend and report back@peerst will check if he can send a delegate too
Wed 24 July 2024 at 16:00 CEST / 14:00 GMT / 10am EDT / 7am PDT / 23:00 JST
2 Likes
mmin
July 19, 2024, 2:38pm
8
If I understood correctly, the Marvin Attack can only be performed when RSA is used. Why did the whole API got deprecated, not just RSA part of it? Is there currently any way to perform asymmetric encryption/decryption in Erlang without using deprecated API?
Why did the whole API got deprecated, not just RSA part of it?
The API is only defined for RSA. To encrypt with an EC key you’d generate an ephemeral key pair with public_key:generate_key/1 and use public_key:compute_key/2 to derive a secret for use with symmetrical encryption. See for example ECIES variants.
Is there currently any way to perform asymmetric encryption/decryption in Erlang without using deprecated API?
Not out of the box, no. You can build ECIES using primitives provided by crypto and public_key, or you could consider using a library that provides proven abstractions like NaCl/libsodium.
But if you know what you’re doing you can continue to use the deprecated APIs, they can be used safely, depending on the exact variant used and the underlying libcrypto version, as well as the threat model of your application.
1 Like
mmin
July 20, 2024, 9:39am
10
That’s correct, I was probably looking some other function’s type specs…
That would help, but I’d like to avoid generating a key pair on the other side of my communication channel.
Thanks for the answer!
It achieves exactly the same thing as RSA encryption, just using slightly different primitives.
With RSA you would typically generate a symmetrical encryption key (e.g. with crypto:strong_rand_bytes), encrypt that key with the RSA public key of the recipient, then send the RSA-encrypted symmetrical key along with the symmetrically encrypted payload. The recipient decrypts the symmetrical encryption key with their RSA private key, and is then able to decrypt the payload.
With ECIES you generate an ephemeral EC key pair, you then combine the ephemeral private key with the recipient’s public key to derive the symmetrical encryption key. You send the ephemeral public key along with the symmetrically encrypted payload. You can then throw away the ephemeral key pair. The recipient combines the ephemeral public key with their private key, which results in exactly the same symmetrical encryption key, so they can decrypt the payload.
In both cases the recipient has a private key for which they have shared a public key, and the message is encrypted in a way that only the recipient’s private key can decrypt. Semantically they achieve the same thing, just with slightly different primitives. ECIES eliminates the need for “asymmetrical encrypt/decrypt” primitives by using the (arguably simpler) key agreement primitive.
1 Like
Participants: @peerst , @maennchen , @varnerac , Alistair Woordman, @voltone
EU:
Cyber Resilience Act , in particular FOSS classified as “Critical Infrastructure Software”Primary angle: consumer protection
Tool: market regulation
US:
Executive Order 14028, NIST Secure Software Development Framework (SSDF)
Primary angle: protect national security
Tool: force industry buy-in through government procurement requirements
EEF strategy:
Ensure BEAM platform remains viable choice for open source and commercial projects
Leverage pressure on (currently passive) commercial users to drive participation in EEF (cf. FreeBDS Foundation approach )
Join Linux Foundation (OpenSSF), other industry initiatives
Obtain grants to help move ecosystem forward
Broader topics (e.g. work being done in @peerst ’s EU RESCALE projects):
Static analysis
SBoM, TBoM
Next steps:
Ericsson looking at SSDF self attestation for OTP
@varnerac self-attestation for ongoing US government projectsAlistair continues to discuss with board and other groups inside and outside EEF
More updates next month
Let’s Encrypt wants to move away from OCSP :
Due to privacy, latency and reliability concerns
Seems they do not consider OCSP Stapling a viable solution
CRLite to deal with big CRLs and avoid latency penalty of just-in-time CRL fetching
Erlang/OTP’s :ssl has known issues with large CRLs :
Post mentions Amazon CRLs of 4MB
More example sizes:
Let’s Encrypt mention their full CRL would be around 8GB (2022)
Using “sharding” they reduced individual CRLs to 70MB
CRLite paper mentions an Apple CRL of 76MB
CRLite intended for browsers on public internet:
Not practical for machine-to-machine use-cases, embedded systems, private CAs
Discussion cut short due to time constraints; continue in Slack or next month
FAPI certification still pending
Checking if EEF can be listed as OpenID member
Wed 21 August 2024 at 16:00 CEST / 14:00 GMT / 10am EDT / 7am PDT / 23:00 JST
4 Likes
voltone
September 24, 2024, 7:54am
13
Participants: @maennchen , @wojtekmach , Paul Swartz, @voltone , @kiko , Alistair Woodman
Though a meeting was scheduled for August, it did not take place, mostly due to summer vacations… Sorry!
Proposal: https://groups.google.com/g/elixir-lang-core/c/J-qZonSYNLE
There are many ways to install Elixir, why do we need another one?
Goal of this one is to have minimal dependencies
Security aspects of running downloaded code:
Downloading code from web is always a risk
Same is true for e.g. fetching packages from Hex
People should have a chance to do due diligence prior to executing code
Don’t write “pipe curl into sh”, to not encourage running without checking
Other aspects:
Proposed to OTP team in the past, but never happened
Now picked up in context of Build & Package WG
Consider static linking, especially to OpenSSL version
To pick up security updates, and not end up with an outdated one on the user’s system
Align with Windows build as much as possible
How to do security updates:
New OTP version triggers a rebuild
What about new linked libraries?
How does that work for Ubuntu builds, Docker images, Windows build?
Need SBoM for OTP, plus tooling
Would be nice to have all those builds in one place, so we can sort this out
Do we need code signing on the binary?
EEF now OpenSSF member:
Adopt elements from OpenSSF Technical Initiatives Landscape (see graphic in channel )
Starting with Erlang/OTP, Elixir, Gleam
Focus on supply chain and vulnerability disclosures
Review the list prior to next meeting
OpenChain :
Also Linux Foundation, so aligned with OpenSSF
Review prior to next meeting
CISA:
Linux Foundation SBoM report :
Call for participation:
Anyone interested in these topics and in moving the BEAM ecosystem forward
Join next months call or reach out to Alistair
Wed 16 October 2024 at 16:00 CEST / 14:00 GMT / 10am EDT / 7am PDT / 23:00 JST
2 Likes
voltone
October 16, 2024, 3:38pm
14
Participants: @varnerac , Bas Wegh, Alistair Woodman, Michael Lubas, @voltone , @maennchen
Goal: come up with a roadmap, get funding
Become a CNA, issuing CVEs for Hex packages:
Mitre is slow
Need to meet registration requirements : policy, public source
Tooling: separate Git org, trusted members, possibly work with Hex team
Voted to kick this off: first look at tooling, then policy and members
@maennchen already started, and will continue to lead this effort
OpenSSF badges, score card:
OTP working on this on their end
For EEF code repos: get Infrastructure WG involved
CISA self-attestation:
Alistair wants EEF to drive this for core BEAM projects
Drew has experience, wants to help
October is CyberSecurity Awareness Month
OWASP & EEF MOU on co-branding and joint marketing
Update our docs to reference OWASP where relevant, remove “draft” label, add a landing page
Ping the Marketing WG
xxx_to_existing_atom/1 PR
PR is here
Need to rework it a bit to align with structure of other pages
Wed 13 November 2024 at 16:00 CET / 15:00 GMT / 10am EST / 7am PST / 00:00 JST (Thu)
1 Like
voltone
November 14, 2024, 9:55am
15
Participants: Alistair Woodman, Michael Lubas, @maennchen , @voltone , @kiko , Paul Swartz
New GitHub org Erlang Ecosystem Foundation CNA · GitHub :
Contains: CNA repo, website
Project with task management
Working on tasks to meet requirements to apply with MITRE
Tasks: scope, security policy
Feedback and contributions welcome
GH teams to manage access:
People who receive and review vulnerability reports
People who are in touch with OTP, Elixir, etc.
Supporting people (e.g. infra, board)
We (EEF) can do self-attestation, despite not being a US government contractor
Projects (e.g. OTP, Elixir, Gleam) to fill in a checklist
Once we apply, figure out how to host it for future maintenance
Alistair in contact with NIST:
Compliance with industry standards mentioned in CISA not strictly mandatory: can have own processes in line with best practices
Working with Infra WG:
Shared documents, defining requirements
GH repo setup:
Code of conduct
Security policy (and “Security” tab)
Next: maintainership
Check out infra WG slack
Was mentioned in a recent talk (slides )
Lots of open ports reported by Shodan:
Many of them running RabbitMQ
Do we have an awareness issue? Can we improve? Blog post?
Can we fix this?
Secure by default: bind only to loopback?
Not much time left to discuss
Continue to raise SBOM topics in Slack channel
Should we pen-test a sample Erlang app?
Develop and deploy a sample app using our own best-practices
Invite pen-testing companies with Erlang/Elixir skills to test it
Collaboration (Google Docs, Notion) and other tooling:
Get people from different WGs together to discuss needs
Wed 11 December 2024 at 16:00 CET / 15:00 GMT / 10am EST / 7am PST / 0:00 (Thu) JST
2 Likes
mmin
November 14, 2024, 10:20am
16
“:” is included in link so it returns 404
1 Like
