| Security reporting | |
| ================== | |
| Thank you for wanting to help to improve the security of iPXE! | |
| If you believe that you have found a vulnerability in iPXE, please | |
| first check that whatever you have found is still present in the | |
| latest commit on the [upstream][ipxe] master branch. | |
| Having checked that your finding is still present in iPXE, please then | |
| check against the defined [threat model][threats] document ([source | |
| file](src/doc/threat_model.dox)) to make sure that what you have found | |
| is within scope and worth reporting. In particular, make sure to | |
| check the "Exclusions" portion of that document. | |
| Once you are sure that you have found something that is still present | |
| in iPXE and that falls within the threat model, please verify that the | |
| vulnerability is real. A working exploit is not required, only a | |
| brief justification of the reasoning. | |
| Reporting | |
| --------- | |
| Please [submit][secadv] any human-written vulnerability report as a | |
| GitHub Security Advisory against the upstream [iPXE][ipxe] repository. | |
| If the vulnerability report is generated by an AI agent, then you must | |
| instead [submit][aisecadv] the report as a GitHub Security Advisory | |
| against the separate [iPXE AI][aipxe] repository. | |
| Do not use public issue reports or pull requests to report suspected | |
| vulnerabilities. | |
| You can leave almost all fields blank in the report. All that is | |
| required is the title and description, which should be no more than | |
| five to ten lines of text. Verbose reports are likely to go unread, | |
| and verbose AI-generated reports will result in the responsible user | |
| being banned as per the "(Ab)use of AI" policy in the [contribution | |
| guidelines](CONTRIBUTING.md). | |
| A good example report (from a real historical example) is as follows: | |
| > `fcoe.c:522`: received FIP descriptor lengths are not validated | |
| > | |
| > `fcoe_fip_parse()` stores pointers to recognised FIP descriptor | |
| > types but never validates that descriptor length `desc_len` is | |
| > sufficient to hold the descriptor: | |
| > ``` | |
| > if ( ( desc_type > FIP_RESERVED ) && | |
| > ( desc_type < FIP_NUM_DESCRIPTOR_TYPES ) ) { | |
| > /* Use only the first instance of a descriptor */ | |
| > if ( descs->desc[desc_type] == NULL ) | |
| > descs->desc[desc_type] = desc; | |
| > continue; | |
| > } | |
| > ``` | |
| That report contains exactly the right amount of information needed to | |
| identify and fix the problem. There is no need to report extraneous | |
| information such as your compiler version, QEMU version, shoe size, | |
| favourite sandwich filling, a Dockerfile, etc. | |
| Credit | |
| ------ | |
| If the vulnerability is real, then you will receive at least a | |
| `Reported-by` credit in the commit that fixes it. More complex | |
| investigations (requiring substantial time and effort on your part) | |
| will be upgraded to a `Debugged-by` credit. | |
| Please be sure to include both your real name and email address within | |
| the GitHub Security Advisory, so that we can give you the credit that | |
| you deserve. | |
| Many thanks for helping to improve iPXE for everyone! | |
| [aipxe]: https://github.com/ipxe/aipxe | |
| [aisecadv]: https://github.com/ipxe/aipxe/security/advisories/new | |
| [ipxe]: https://github.com/ipxe/ipxe | |
| [secadv]: https://github.com/ipxe/ipxe/security/advisories/new | |
| [threats]: https://dox.ipxe.org/threat_model.html |