New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

POK kernel security vulnerability #9

Closed
sduverger opened this Issue Sep 26, 2018 · 9 comments

Comments

Projects
None yet
3 participants
@sduverger
Contributor

sduverger commented Sep 26, 2018

Hi,

We discovered a serious vulnerability in the POK kernel. A patch is ready for a PR.
We already exchanged with POK former author Julien to responsively disclose the findings.
Please tell me when you are ready to deal with the PR or if you would prefer us to provide you with a PATCH privately to have time to analyze it before any public release.

@Etienne13

This comment has been minimized.

Contributor

Etienne13 commented Sep 26, 2018

Hello,

Before the PR, I guess your code is available on a git repository that we can clone to test the impact of your changes on other tools. After this step I can give an answer (and other users of POK too).

Etienne.

@sduverger

This comment has been minimized.

Contributor

sduverger commented Sep 26, 2018

Hello,

I forked POK (check my github), do you want me to push my commit ? If I initiate the PR, before acceptance you would be able to have a check on it. But as I said, it would make vulnerability public before official POK repository fix.

Would you like me to send you a patch instead (email + GPG ?)

@juli1

This comment has been minimized.

Contributor

juli1 commented Sep 29, 2018

Stephane,

Please send me the patch, directly through e-mail. I will test it and make sure it does not break major functionalities.

@juli1

This comment has been minimized.

Contributor

juli1 commented Sep 29, 2018

Website updated there: https://pok-kernel.github.io/
Please send the patch, I can check it, integrate it and update the security disclosure.

@Etienne13

This comment has been minimized.

Contributor

Etienne13 commented Sep 30, 2018

Stephane, Julien,
after receiving a description of the patch by email I would say I am ok for its integration as I believe it will not impact functionalities.

@sduverger

This comment has been minimized.

Contributor

sduverger commented Oct 1, 2018

@sduverger sduverger referenced this issue Oct 1, 2018

Merged

fixes #9 #10

@juli1 juli1 closed this in #10 Oct 2, 2018

juli1 added a commit that referenced this issue Oct 2, 2018

@Etienne13

This comment has been minimized.

Contributor

Etienne13 commented Oct 2, 2018

The merge contains a problem: at link time of the object files, I have the following error message.

syscall.c:290: undefined reference to `pok_ports_names_max_len'

Indeed, pok_ports_names_max_len is defined as extern in syscall.c.

I guess the variable definition has to be generated by third party tools, but how to compute the expected value? If it is a constant, why wouldn't we use maccros like for most configuration parameters of POK?

Appart from this, and after setting pok_ports_names_max_len to an arbitrary value, it works fine.

@Etienne13 Etienne13 reopened this Oct 2, 2018

@juli1

This comment has been minimized.

Contributor

juli1 commented Oct 2, 2018

pok_ports_names_max_len is produced by code generators when there is any communication. If compilation fails, this is either because the code generator has a bug or the syscall.c file is missing an #ifdef (or something similiar).

While this is related to the change of this issue, this is not a security vulnerability per say (some generated code will work - the one generating the pok_ports_names_max_len variable).

Let' keep track of that in another issue so that we can clearly address one problem per issue.

@Etienne13

This comment has been minimized.

Contributor

Etienne13 commented Oct 2, 2018

Done in #11

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment