All right, then, let's continue concluding this cheesy
segmental step room at first term 2026 with the final presentation today.
Pairic Philippe also has made a decision in life, different one than Jose and his decision
was to come back every two years with GCC analyzer related presentation.
So yeah, this one is about the proposal of a secret attribute.
So I'm here to present an ongoing work on the definition of a set of attributes for a secret
within GCC.
And more specifically within the analyzer for now.
So for those few who doesn't know, so in 2020, there was a stage analyzer introduced in
GCC, and so it doesn't operate on a gimbal, so actually quite just at the late stages
of the middle end, actually.
So it does leverage an optimization dependent analysis.
So of course, it's only on the middle end, so all the analysis on the back end are
not seen by the analyzer, of course.
And so it is quite nice frame, actually, for a section to relate to the analysis, so far
it does mostly have memory related analysis.
So for example, the analyzer is able to detect an open to the reference in the procedural
context.
So here, for example, you have a dummy program with a lasing and here, in the food
function, you have the null points or the reference happening.
And here in the terminal, you can see that the analyzer is able to have quite nice diagnostic,
quite easy to understand, thanks to David Malcolm work, as I don't think he's here.
So you can see that there's a number and ordered event, and so it's quite easy to understand
at a different pass, leading to the issue.
But unfortunately, there are other kinds of issues than memory related issues in C-program.
One of them are related with secrets, and here, for example, you have, so it's a quite
unique technique and vulnerable authentication, so you can see that the developer here
is allocating space for a password, then get the password from the user, it validates
it against an expected password, which is here, are coded, for example, so you should
never do that, obviously.
And depending of the validation, well, the program returns a result.
And for some reason, the developer here decided to say, well, how the validation failed.
So I was expecting actually the full-marked password, so we ran me again and then we're
good.
So obviously, you shouldn't have a do-that's.
And actually, well, this is not detected by the compiler or by the GSA's.
And so this first of all, because, well, this is not possible, and it's due to a semantic
gap, actually, between programming languages, I don't know if it's possible in Algorithm
or in Algorithm's, and secret leakage, actually.
And so we focused on C here.
And so usually, we describe our programs with two, this joint set of properties.
So on one hand, you'll have the functional properties.
So basically, what your program should do, or not do.
So for example, your program should not crash.
And the other set is the set of the non-functional properties, which are basically describing
everything else.
So for example, is your program doing what it is doing in a safe way, or in a secure way,
regarding this or this model.
And actually, memory-related issues, such as the no-point of the reference, for example,
well, that's a violation of a functional property.
But printing a password is a violation of a non-functional property.
And so that is outside of the compiler, actually.
And so this is because mainly C, for example, has no concept of secret variable that's
all.
And so there has been a lot of tools and work to target secret-related issues.
But usually, they are tied to specific vulnerability, or a set of specific ones.
And usually, they are tools outside of the compiler.
But according to some surveys, here you have both work from academic and industrial
word.
So there are actually two problems coming out from a lot of tools.
One of them is that some tools require developers to break their blocks, and so, well, if
you need to use a tool that will break your habits, well, you probably won't use it.
And the other thing is the diagnostic itself.
So if a tool has a complex or a noisy diagnostic, well, you probably won't lose time
trying to understand it.
And actually, those are usuality issues.
And so, we think about it, and we thought, well, actually, this is already part of
a lot of developers work flow.
And also, well, the GSA already implemented quite a nice reporting system, as we've seen.
It is also trying to go for a soundly analysis, so that means, try to aim for soundliness.
So that means, as sound as possible.
And so, we asked ourselves, well, could we detect secret dependent data being passed to a
leaking function within the GSA?
So here, secret dependent data means that sometimes in your program, well, your secrets.
So, for example, the password or cryptograph keys, well, they might propagate it to other
variables during your program's execution.
So here, for example, you have the secret variable, which is secret by definition, and the
X variable, which is initialized, depending of that secret.
And here, X is depending on the secret.
So it is secret dependent.
So we tried to think of a set of attributes to identify and mimic the behavior of the
secrets in the program.
And so, at the first stages of our thoughts, we were actually returning on something which
is close to the binary model.
So we are still thinking about memories and registers, but actually we are in the compiler.
So we were thinking, well, maybe we could resume on the programming language itself.
Because it has several more advantages, because, for example, programming language, well,
they have meets our information on variables, for example, such as Swiss fires, but also
it was cooked and a type.
Whether in binary, well, a variable doesn't exist.
There is only the registers and addresses.
But it can also work for the concept of function, because in C, for example, well, your
function, they might be defined or on it declared, and they have, or not, they may or
not have inputs, so for example, parameters in C.
But they also may have one or several outputs, such as a written value, but they could
also write to one or several of their parameters.
And this doesn't exist in binary, also.
And so we tried to think about the different ways to create secret in C.
And so we came out with four different ways, so the first one is actually quite easy to understand.
It's a local variable.
You have a local variable with an inflection, and you know it is secret, because for example,
is a password.
But there is also the notion of type.
A type might always, by definition, be secret, such as in every case, for example,
the private key will always be private.
And you have also two other cases, which are the fact that some function, you know that
one of the parameters will always be secret when you call it.
So for example, an encryption key of an encryption function.
So in that case, that means that when you enter that function, you should always consider
that parameter as being secret.
And another case is more type to secret generation function.
In those case, for example, when you're generating random, you might want to check that
you are not returning zero.
But in fact, checking your secret against another value is actually leaking information.
It's a constant time vulnerability, bailation.
And so in that specific case, you might say, OK, so I know that this will be a secret,
but only at the end of my function execution.
And so we designed three field sensitive attributes to identify secret.
So the first one is the secret attributes.
So it can be tied to variables or parameters, but only to define functions.
And so in that case, that we mean that the decorated parameters will be considered secret
from the function entry.
So for example, the encryption function, previously, that I shown previously.
There is the secret attributes, which can be tied to parameters or written value.
So here, it can be applied on defined or in defined functions.
So for example, it can be applied on headers, for example.
And the secret type, of course.
So this means that it can be used on type definitions, for example.
And in that case, it means that each instances of that type will be considered secret
at declaration.
But so OK, we can identify secret, but that's not enough because, well, there are some
function that have side effects regarding secrets, such as memory copy, for example.
So if you take a password and you copy it somewhere, well, the destination of that memory
copy should become secret too.
But there are also some distracting functions, such as B0, for example, which we know will
result in the secret being destroyed.
And since we want to detect some linking function, we also call them the answer function.
So those are the functions that should never be used with secret, because we know that
they link information about them.
And actually, those function, we don't need to have access to their definition.
We only need a way to be able to identify them.
But one way way would be to say, well, we just have to manage a use database with all
the functions.
Well, actually, it's quite impossible, of course, because you can have project specific
functions, such as project specific memory copy or even distracting functions.
But also, some linking function might be conceptive dependence, because in some cases, for
example, the length of a buffer should be considered as secret, but not in other cases.
And so we designed three function attributes.
So the propagator attribute, which in this case would say, okay, so the source, if it is
stented, it is secret, then the destination will become secret.
The structure attributes and the unsafe attributes.
And so we implemented this attribute system alongside Tane's propagation mechanism within
the GSA, so within a state machine.
And we called it Gnosecrit.
And so, thanks to Gnosecrit, we are currently able to detect this dummy program as being
a real normal here.
And so this is an ongoing work, and so to conclude this talk, I would say that we are trying
to leverage a secret analysis within Gnosecrit through a set of attributes.
So this is interesting, because attributes can be safely ignored by compilers, so that
means that Gnosecrit, so that means that some projects could use Gnosecrit related, vulnerability.
So I will still be able to compile with, for example, or CLAN.
And so currently we are still working on the evaluation of Gnosecrit, so namely the false
positive and negative rates.
And our current approach is to use a tool to generate random C programs, such as YRGEN,
for example, to use data flow analysis to find different dependencies between variables, and
to annotate the code in a, but the magic way to then run our tool, and yeah.
So the idea of this talk was to be able to have a return from the community, maybe, so
you said that if that was you think it was, it's not okay, to have feedback actually.
And even if you have any experiences with generating random C programs and annotating
it in automatic way, well, please, I would love to have anything.
And so feel free to reach out.
There is a link to my website, so it's definitely not updated yet, but yeah, thank you.
I'm here to ask you, do you plan to expand the impact of those attributes out of this
that I can analyze her?
For example, if some variable is secret, you will have a little bit memory, you can kind of avoid
that.
Okay, and that's one, so that's one, because also the functionality and not functionality
goes, I'm thinking about verifyability.
So I would love to see other attributes for all the non-functional processes impacting the
behavior of this mutation process, do you plan to go there?
Okay, so the question is regarding the attribute themselves, or they're tied to the
static analyzer themselves, itself, or outside of it.
And also do we plan to extend them to, so for example, an optimization passes.
So the first question is the answer is yes, it kind of is outside, because it's actually
plug-in, so thanks to I don't remember the, but you can define attribute by plug-in.
And so far it's only a plug-in to test our ideas.
And yeah, we would like to go there to, to go to make some optimization passes, such
as that search validation, for example, aware of, so those data are secret, so we should
not, for example, deal it, call to a man's set, or something like that.
There was one question on the line, maybe we should take that to give them a chance.
Yeah.
How much of this C-C-Prid property is based on Perl's Tainter concept?
Okay, so the question is regarding, so the Tainter propagation, I think, and the fact
that there is an implementation, which in Perl, I think, so it goes back in, I don't remember,
but it was in the 90s, I think.
So to, in Perl, I think it was to analyze secret, but mostly password and things like that,
as far as I know, and it's pretty much a similar idea, actually.
The idea is to push it on, on the compiler, such as just a C, for example.
And so we focused on C because there is actually a lot of cryptographic code developed
in C so far, and so the idea was to go for C first and then see if we could go, well, to
grow the language, to, I mean, to, why didn't the different target languages?
Yeah.
Okay.
Okay, so the question is regarding the condition of propagators on the custom memory, for
example here.
So here that means that this nation, after the evaluation of the call to the custom
copy function, the destination parameter, so the argument at the call site, will be considered
secret if and only if the parameter here is secret.
Yeah, but thanks to the analyzer, the source could, for example, not be fully tainted, so
not fully be secret, but the analyzer is aware, thanks to some
it's true, it's memory model, it's able to only propagate, for example, some pieces of an array
or of another integer, if it's regarding the type, I mean, we haven't pushed that far,
the test we're going to type attribute yet, but that would be interesting to see if the analyzer
attribute, I think it can, I think that is Malcolm worked on that, yeah, yeah, the secret
attribute for the array, yes, related to the mindset that there is a normal version of
mindset that is, yeah, mindset S, for example, yeah, I don't know, there's enough, a new
version of mindset that was added to the C23, to enforce the website even if it lives
useless, okay, so anything containing a separate must be clear before you answer the function,
yeah, yeah, yeah, so actually this work is based on
traduce work where we were detecting missing the realization, especially of secret, yeah,
oh, no, no, this is C23 standards, actually, yeah, this is C23 standards, to also the question
was regarding this annotation, but what were they thinking about, yeah, so it's C23 standard that
pushed some standard, yeah, but I mean, so far we are still using the old, this was just to fit
in the presentation, so far we are actually not C23 compile, well, compiling, yeah, yeah, so how
exactly are you getting the compiler in the course in constant type guarantees? Oh, we're not,
so the question was regarding how do we enforce the compiler to respect
a constant time guarantees, so we're not, because actually the analyzer so far is only,
it kind of is a huge abstraction of the DCC itself, I mean, it's easier to go
within the analyzer than to start digging into the whole compilation pipeline of DC,
and so the idea was to play around first, be able to see if we were able to detect some problem
and the idea behind the propagation, well, the attribute is to make them available to the whole
compilation pipeline, and maybe if we are able to detect it in the analyzer, then we should be able
to make it, well, to make, for example, the necessary nation pass, aware of that, but also some
optimization pass, such as, okay, you're using if on the constant, so you should, for example,
use the, I don't remember the instruction in x86, 64, but the select, yeah, yeah, just seem with
it, for example, yeah, yes, I'm not sure, I didn't understand, I can't extend your work,
it will also have a biores, or the ratio of just enough. Yes, so the question is regarding to
extend the work to other, so for example, card generation of the compiler, and yes, I would love to,
but so far, since it's, we only want to first test these set of attributes, see if it fetch,
we would love also to have feedback from cryptographic developers to see if, well, that much
actual usability, and then, yeah, we would like to, after having an analysis, we're moving to fixing.
Yeah, but the analysis will be done by the static analyzer, like doing all those preparations,
and every speed, and then, I don't think, in the notes, in the simplest sequence of objects,
so far, their classes will make use of the information, just take the rest. Thank you.
So, I think there is a few questions behind, which is? No, I'm not, I'm actually excited because
on the previous site, we have a similar issue with building biopivity. Okay, yeah, and for the first
time, we are going to have to get the optimization passes to alter the behavior, not necessarily
based on functionality requirements. Yeah, and what they see here is the same thing. Exactly, yeah,
it's like the different, but it's the same, so we can't keep. Yeah, I would love to.
Could you speak a bit loud? Could you speak a bit loud? Could you speak a bit loud?
How do we take what a secret gets leaked? Like, do we have a major data based with all functions
that are classified as leaking or how do we handle that? Okay, so the question is, how do we detect
when the function is leaking? Actually, depends. Depends of your secret, depends of your model.
For example, if you consider a constant time programming, you know that some function should never
be used with secret, such as comparison function, such as the main compare or STLN,
so some function like that, you know they should not. But outside of that, it depends.
For example, in some context, I was thinking about STLN, and in other contexts, for example,
so the length of a buffer, for example, as I said, in some context, the written value of STLN,
for example, or the size of that buffer, will be secret. But in other case, you don't care.
So that really depends on the project. So that's why we wanted to make it
through a set of attributes. This is the user that have to set it in their headers, for example.
I don't know if there's time yet. Yeah. Yeah, I am the last one. Let's go.
Oh yes.
things that you have to buy to a bottle?
Yeah, for the question is regarding having the
pain propagated between devices?
No, no.
Multiple different things.
Oh, okay, so different things within the same, okay.
So far, we haven't think about that to be honest.
Yeah, I'm not sure if I can see a use case, like, because I'm not sure to understand
the use case beyond it.
Can you show us some examples?
Yeah.
Another example is the nearest product that we have a tool for class.
Okay.
The checks for points are compensation in which the best thing is the assignment.
Oh, okay.
Okay.
As it points us, like all the ingredients you've pointed out are monetary, and then it checks
out.
Okay.
So I think it might be, I mean, the base work would be the same, probably, but you have
to redesign the propagation mechanism themselves.
Okay.
Yeah.
Okay.
So the unsafe activity seems focused to me or other people, because
every function is could be leaking.
Can you kind of expect everybody to flag every function with the unsafe activity?
Yes.
Yeah.
Most functions would be considered unsafe, and dealing with the secret has to be done
properly with only specific functions that you have checked out for and so you can.
And the, I said, that doesn't get, I can confirm myself.
It's called Nensei explicit.
Okay.
That's, oh yeah, right.
The presentation probably is that because the code in the display, the last two lines
will be erased, but to my end.
Yeah.
Of course, yeah.
Okay.
So yeah.
About this, I mean, yeah.
The unsafe or safe, it's, I mean, it's a, it depends because for example, there's some function.
You don't want to be able to flag them as safe.
Depends of the programming language, of course, for example, additions in C++ or actually implementation.
And so it's a function called, for example.
So, and I don't know how it's, because I haven't looked at the gimbal as a say,
an intermediate representation of C++.
So, I don't know if, for example, addition is a function called or not.
And it's the same.
Okay.
So, I'm not sure.
I don't know.
It's, yeah.
I take the remark.
I have to think about it.
Thank you.
I have an answer.
Okay.
Let's take care of it.
Okay.
You mean rest?
No.
And what I'm doing?
Okay.
Let's secure it.
Yeah.
Unsecured.
Okay.
Thank you.
Okay.
Thank you.