@admin I wouldn't request a CVE for the authorization issue here, but for the potential DoS I'll let @maintainer decide

We're going to handle this as two separate problems and we would like a CVE number for both of them. However, I can also just order the CVE-Numbers via GitHub if that's OK for you.

Yeah sure, if that's your process anyway I don't mind. - @admin can you assign cves to this report afterwards?

FYI: there is now a PR with a fix at https://github.com/bareos/bareos/pull/1115

Absolutely, we can assign a CVE for this. Can I just confirm that a CVE has not already been requested from GitHub, just to prevent duplication of CVEs? Once I get your confirmation @arogge, I will assign a CVE to the report.

@admin In the meantime I have requested CVEs for both issues at GitHub (I may have misunderstood the ysf's comment). If you could add the CVE numbers to this report, after they're issued, that would be great!

@admin due to improper disclosement in my part - I put two topics in one report - we know have two CVEs. Should I add another one or can you add two CVEs afterwards.

@maintainer @ysf - no worries 👍 Let me know the IDs once you have them!

We can attach a single CVE from a UI perspective, but we will just make the other CVE number visible in the comments section.

@admin Andreas wrote me that he can't choose myself for the fix bounty. Do you know if there is any technical issue? Maybe because his refactoring cleaned other lines that I mentioned?

Having one makes a difference community wise as I assume it'll be one cve, vulnerbility, fix and bounty on my stats - That said, it is truely ok for me to do so since I'm doing this for the bigger picture. There might be a use case for the other researchers tho, especially when there is a bigger bounty involved.

@admin we got Numbers: CVE-2022-24755 for the Authorization CVE-2022-24756 for the DoS

@ysf turns out I cannot read properly: I can select who's going to get the fix bounty at the bottom of the "Confirm Fix" form. As always you just have to read till the end...

However, what seems to be not possible is to mention multiple fixes. We're going to fix these issues for all supported releases, which I would like to document here, too. Maybe @admin can tell me how to proceed in this case?

I'd recommend that we use the CVE and fix for the Improper Authorization issue, and then can just keep the CVE and commit references for the DoS issue in the comments section here.

@arogge - feel free to confirm fix using the commit SHA that addresses the Improper Authroziation, and could you please let me know which CVE is being used for this as well?

@admin the Authorization issue has CVE-2022-24755. My Problem with the commit SHA is, that there will be four of these: one for the development branch and one for each of our maintenance branches.

I see - perhaps we can use the commit SHA that is merged into your main branch, used for releases - i.e. a merge commit SHA with all included?

If it was just that simple... I'll go with just the master-commit.

Okay 👍

It sounds like we could definitely benefit from a new feature here, around attaching multiple fix commits?

If you feel strongly about this, I'd love to invite you to create a GitHub Issue our on public repo where we track feature requests:

Create feature request

I wrote a FR, see https://github.com/418sec/huntr/issues/2201