last year.
Hello, everyone. Last year, first time, I was talking about
errors in embedded development. And I would like to repeat a part
of the experience that we have had last year.
Please think about an embedded project you are working on
or you have been working on recently. Lock it in your memory.
No cheating. You lock a project.
Now, how many open SSL versions are there in that project?
Raise your hand if that's zero.
Like 10 people.
Raise your hand if there's one.
Like 20 people.
Raise your hand if you are sure there are two or more.
Like less. And raise your hand if you do not know.
That's the majority of the room.
I think there are a little less people who do not know,
but still the majority.
Why the question is important? You will see later.
And a bonus question for people who knew how many versions of
open SSL they had.
Who can list the total, who of you has a full list of
dependencies of that project?
Okay, I round 20 people. Congratulations to you.
Now, who is Marta and why she is talking about such things
and asking such intimate questions?
I'm a security researcher.
And then what to expect from the 2024?
Now, let's talk from regulations.
Regulations that plural are a little bit too much here.
One regulation. Because that's a 25 minutes version of the talk.
So, their regulation is the CRA.
Now, one slight simplification of CRA.
To your lawyers, I am simplifying.
The CRA is adding security, mandatory security requirements
to all products that will be put on the market in the European Union
by the requirement of the C-mark.
The C-mark, you know it, on all electronics you have the C-mark.
It's extending the C-mark to add security, mandatory requirements.
Examples of the things that are mandatory.
No release with known vulnerabilities.
As bonds.
Secure configuration by default.
Updates by default for all users.
And so on and so on.
There are two pages of those requirements.
In the final version, it doesn't apply to open source project themselves.
In most cases, it applies to products that are integrated open source.
All products, in fact.
It will require paperwork.
Mainly risk analysis and the vulnerability management process.
And what this paperwork will be, I cannot tell you right now
because it's going to be defined further.
As for most of the things C-related, you have self-assessment by default.
But there are certain classes of products that will require more.
Including external security audit.
That's an expensive thing if you haven't done one.
And that's hot news because we have a final version.
It's expected to be voted next month.
And from next month, there will be three years till the final implementation.
Now, the current version excludes non-monetized open source project.
That's a big simplification also.
So if you are contributing to an open source project, it doesn't apply to you.
But for all integrators, embedded people are integrating open source in their products.
So basically, it applies to the whole embedded.
There will be risk analysis to do for all components that you include.
And that's why the question of what do you have as components in your project is important.
And now the big question for the whole embedded open source community.
Is everyone going to do this paperwork alone?
Or are we going to do the paperwork the open source way
and share the documentation prepared for each single dependency?
That's a big question for 2024, for all of us.
If you want to know more, if I scared you enough,
I've written an article published at WN last year, so it covers the first version.
And for your trip back from FOSDEM, there's a nice read, the final version of the regulation, just 189 pages.
But it's not boring.
I didn't fall asleep, it's not boring at all.
Now, let's go to trends, apart from the regulation.
CV numbers. What is a CV?
CV is a way to name vulnerabilities, public ones.
It stands for common vulnerabilities and narration.
And the number of registered public vulnerabilities is growing up.
And in 2023, it went up. Yet again, we have yet another year of a record high number of CVs.
I haven't been splitting embedded, non-embeded, but for embedded, that's the same statistics.
The number of vulnerabilities is going high in a very important way.
Now, a complex problem of funding of security work.
In the recent two, three years, and there was a big part of this process happening in 2023,
there are external funds paying for security work in open source projects.
Two main examples of that, OpenSSF Alpha Omega project that funded, I've chosen examples from the embedded field.
OpenSSF Rust, Python, Eclipse Foundation, and the Sovereign Tech Fund that has been
part of the work for the Yocta project and other projects too, but in the embedded field.
Because of this funding, because of the pressure of the regulations that are happening not only in Europe,
in the US there's also different pressure, but in the same direction,
we are seeing the update of processes in different projects.
An example of that, the Yocta project has now a security team and working security process.
In relation to all that, we also have tools that are either being implemented or they are being used more and more frequently.
For example, the S-Bomb generation, either in the Cyclone DX or in the S-Bed X format,
that is getting more and more common option.
In embedded projects, yet another example from our field, S-Bed X is now generated by default
in the Pocky reference distribution in the Yocta project.
And a similar tool link on the dependency checking and CVEs, you have that in the platforms like the Dependable on GitHub,
Standard on Tools also, tools are happening and the pressure to use them is happening too.
And another big question for all of us, all that work, it requires someone to do it.
To do the security work, to do the processes, to look at the results of tooling,
even if they are the CI, you have to have someone looking at the results.
How can we do it long term and especially how we can fund it long term?
Those external forms may disappear one day.
Big question for 2024.
Now, for the events, vulnerabilities and incidents, I had to cut things
because I want to have time for questions and it's only 25 minutes, so I had to cut.
And this is what I have chosen for this year.
HTTP2 Rapid Reset, also known as CV 202344487.
This one was actually exploited in practice between August and October of last year.
And it's a vulnerability in the HTTP2 implementation,
or a little bit in the specification itself also.
And if a client creates a parallel stream,
HTTP2 allows parallel streams for the same connection,
if the client creates a parallel stream and just immediately after sends a message to close that parallel stream,
this is generating a high load on the server.
The creation of stream is pretty expensive.
And as a result, you get a denial of service.
Most HTTP servers have been affected and there was a big number of releases happening in October 2023.
What is interesting in the whole story is that the servers that are more for the embedded market,
so with careful resource allocation, with limitations of number of clients,
or limitations of streams per client,
they had better resources, less vulnerable to this issue.
For example, like HTTP, they clearly state that they are not vulnerable to that issue.
I'm providing a link to the NVID entry for that problem,
with dozens of links for different projects with information,
or what they did, or what they expect users to use as configuration options to prevent such things in the future.
And then a little bit of fun.
It's either funny or it's frightening, depends on how you read it.
The whole thing happened in 2022, but it has been published in 2023,
so we can say we put it in 2023.
This was a long story, but in short, some trains in Poland weren't starting after maintenance.
And the maintenance company took a team to the river engineering company,
and what they figured out that there were things like,
train was locking with a vague error message after staying in one place for a long time,
or the train was reporting errors after staying at some GPS positions,
which by coincidence turned out to be GPS positions of workshops of the competitors of the manufacturer.
Or in some trains there was a log based on a date,
well, related to the CERA, but also related to all the things happening on the market.
Until now, embedded developers were choosing their dependencies.
Well, it does the work, I can take it, if there is a license matters.
In the future, it may be that license matters won't be the only condition.
There may be also a condition that this project have security policy,
is this project providing regular security updates for five years or more,
and there may be the need to do the triage in your dependency list,
in some surprising places also.
On the S-Bomb site, last year we have had S-Bombs being generated in more and more places,
generating S-Bombs at school, but it's even more cool to actually use them for something.
So I think that's going to happen this year,
and then on the pure vulnerability side,
we are still seeing products being developed to be in an internal network,
not connected to the internet, and then someone puts a GSM modem in there.
I am expecting a few funny vulnerabilities like that.
Then the hardware series is going to continue,
not only chips but also firmware.
Have a look at the size of the firmware of your network card,
or your graphic card, or your gpu, or other thing, or phone chipset.
That amount of software means there are bugs.
If there are bugs, they are also likely security bugs.
I expect that, maybe not this year, but sometime in the future,
the future will have a big issue related to firmware in one of those categories.
My personal pick is network cards, a packet to make things funny.
Then there may be also issues in places you do not expect them to.
Quite many open source projects have never issued a CV before.
If they have never issued a CV, users have a tendency to not update them.
Not having a CV does not mean that there are not any bugs.
In fact, quite the contrary.
I expect that we may have an issue of a very serious problem happening
in one of those projects nobody has been looking into before.
Then everyone will be trying to figure out how many copies of that project they have.
To sum up, that is going to be an interesting year.
Do you have questions?
Thank you for the interesting talk.
I have a question about the legislation.
Are there different regulations for real security bugs and denial of service bugs?
If you have some warmable hole in your software, which is network-connected,
or something which is a denial of service, for me it is a different class.
In one case, you probably get my point.
There are two parts of answer for your question.
The CRA is not the only regulation that is currently in progress.
You know that there are European elections in Germany.
Things are being rushed.
There is the CRA, but there is also the PLD.
There is the regulation related to the workings, there is the regulation relating to AI,
and all of them have certain things.
On the typical vulnerability in the US,
if it is an exponential like in the case of that HTTP repeat reset,
it is a vulnerability.
I classify it with a typical vulnerability.
If it were to happen in a network device,
that also enters into other regulations quite probably.
There may be things that apply in different places,
depending on the actual use of the same software.
Thank you very much for this talk.
I think this is probably the most important talk to me,
as I am a designer manufacturer, embedded hardware for startups and SMEs.
I am desperately concerned about the situation.
The timeline you lay out is scary enough,
but you will know that we in the UK have IoT connected device law
coming into power at the end of April.
We have three months to be compliant to this.
There is a £10 million penalty, potentially, to us,
or a percentage of global revenue.
I will say broadly not one of the startups or SMEs we work with,
and indeed ourselves, are in a position to deliver on this stuff,
which scares the heck out of me.
I would love to know who we need to be talking to to work together
to try to look at this.
I haven't shared the scary part of the series about the penalties,
but in all cases, you are not able to pay them, so...
That is another example.
In different places, there are different regulations being brought in the light.
For me, as an open source community,
we have the only way to solve it all together
and prepare the whole paperwork all together.
Otherwise, the big ones will be able to pay the whole paperwork,
but the small ones, well, not really.
I think we are out of time, unfortunately.
Thank you.