QtCS25 - Qt & Cybersecurity

Session Summary

The CRA is starting to be a hot topic for a lot of customers. We're trying to use this as a vehicle to actually improve the processes and tools for the Qt Project. Let's discuss where we are, and what are the next steps.

Session Owners

Kai Köhne

Alexandru Croitor - notes

Notes

Qt security score markers in files.

One conclusion: mark all files in library code, but not examples or tests. Mark with insignificant when it is so, so we don't need to question it in the future.

Tooling could scan the markers, to warn on creation of new files without the marker (perhaps from Bots)

Benefit: it's easier to have it in files, than in abandoned gerrit changes, because its close to the files, and abandoned changes are hard to fine

Should we move critical functions outside of files into critical files, when most other functions are normal?

General consensus - yes.

But the file granularity stays, not at function level.

We should have reasoning for insignificant marker as well, to avoid re-discussion in the future.

Discussion about wording about what is and isn't security-relevant (for example about security boundaries of qtsvg).

Is there any feedback on the UI team security reviews in Oslo? Is there anything useful for everyone else to know? Guidelines? Should be in intranet.

Started with a lot of files that were critical, but then reduced the amount, and adjusted the docs, saying that we need to trust the input.

If the protocol is documented as not being security-safe, then the Qt data parser is not security-critical, but we should document that it's because of what the protocol says.

Ivan says he trusts input from dbus, because you need root privileges.

Thiago says he trusts file input that comes from kernel, because kernel is not out to hack you.

We should do more fuzzing. Some parsers are missing, like data url parser.

Thiago: We should provide a small tool that the fuzzers can run to discover issues in mimetypes, data url parsing, etc.

Ivan: If there's a dynamic buffer allocation than can overflow, but it's not data parser, crypto, etc, how do we categorize it? Where's the border? Should we mark them as critical? Opinion: That's just regular code reviewing. So maybe we don't need the marker?

What is critical vs significant?

The marker is also about spiking a discussion.

Tools like windeployqt crashing is not a problem, but it's a problem if it generates code it might be.

In the end the audience concluded that after a library code review is done, we will not mark changes as insignificant, but only either significant or critical.