OpenSSF Vulnerability Disclosures WG, 26 Apr 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OpenSSF Vulnerability Disclosures SIG Autofix (April 26, 2023)

Description

Meeting minutes: https://docs.google.com/document/d/1mZEi6EvbH2mvn-gHOUIaysAjHlwJXjJdJ7gMlelSkVU/edit#heading=h.u5im5d90xac4

Repo: https://github.com/ossf/wg-vulnerability-disclosures

A

B

Help if I click on the right, Zoom link.

C

I've done that a couple times too, just like.

B

Yeah where's everybody yeah hi, everybody yeah.

A

B

I asked um slack or I asked chat, gbt the question um because I'm working on data flow and control flow analysis and and I'm like can inter-procedural control flow analysis and data flow analysis performed against Java project by only visiting each file once and chat. Gpt came back with a very interesting answer. Now. I'm, like you know, trying to I'm it's a you're like I, have a question: Google's not coming back with the right.

B

You know anything meaningful and or there's long or like articles written by scientists in math terms that you can't understand, like maybe chat, GPT could like condense, this down into a more readable format. So.

B

um Yeah did it work? um Yes, it came up with something it came out with something that is plausible. Now, okay, you can't right. It's like great, like.

C

Yeah, how do I fact check this yeah? How.

B

Do I fact check this right because yeah exactly.

C

Yeah, that's the fun thing with GPT right is. It gives you plausible sounding answers and then it's up to you to figure out if you believe it or not, yeah.

B

C

um It reminds me I was using it to generate some code the other day and uh it generated some really nice. Looking Ruby with libraries that didn't exist.

C

It's like yeah. This would be great if that actually like worked yeah.

B

Yeah I assume assume this works.

B

B

All righty, then um I'll go will be joining us shortly, but their customer meeting is running late. uh I am going to slap. The oh I have not yet created the chunk of uh like the APAC Hollows. This is the 27th. Okay, that's the next day.

B

Okay I need to I need to copy the previous Sega meeting autofix egg.

D

B

Bring that up here, put it under the APAC call.

B

Wait: curled Mike butchering the notes.

B

I'm sorry, what am I butchering the notes? I'm.

E

B

Hey it's okay, I, don't know, I'll, take a look: okay, I'm, hoping to not butcher the notes. Thank you for being here. Bro I know, you've been busy and stuff all right. Let me let me make this all uh uh all right, y'all could fill in your names for the autofix Sig.

B

That would be greatly appreciated because every name brings us closer to being a real Sig instead of just a fake Sig and actually also the more organizations that are shown up here so I'll Place past post, the uh the notes in the yeah there we go.

C

Is the date supposed to be 26.

B

Yeah, please please.

C

Feel free to fix my.

B

B

B

Okay, um let's start out with Annie new friends we have for today you have any new friends. Anybody who hasn't been here before anybody want to introduce themselves anyone you want to say hi for the first time.

B

Okay, um we might have Jonathan joining us shortly, um but I don't know if I either live either or Jonathan. So we'll see um John if Jonathan joins it's uh Jonathan schneideries the CEO of um uh uh modern, see if I can manoir usually shows up at these too and well. He hasn't recently um I'm just giving a ping. Okay, um all right. There are two there there are. There are two people that have added their attendance to the meeting notes and there are five people. There are seven people in this call, so I'm ordering.

F

Doordash I'm so hungry that needs to take precedence.

B

All right all right, please do Mark your attendance in here. um It would be greatly appreciated. Chrome I got you.

B

um Okay, thanks fans, so uh all right who wants to help us out and Scribe today.

D

I will scribe today.

B

Thank you um all right and then opens and then uh meeting agenda.

B

Our meeting notes do we have any opens anything that anybody wants to bring up, discuss, yada yada.

F

Talk about disclosure track! What talking about disclosures disclosure check that the tool? Oh yeah, yeah,.

B

Yeah yeah um you wanna, do you want to do a um the disclosure check? Is the thing that you wrote? Can you uh do not just talk about it, but can you throw like show a demo of it? I.

F

Can do it if we talk about something else for like two minutes: I'll have a demo ready um like you can talk about it, but then I I can't type and talk yeah.

B

I get it I get it so yeah um that'd be awesome if you could yeah um and order your doordash already done great um okay. So we'll do that. um uh Yesterday's meeting no last two weeks, ago's meeting um oh before I, get there um I, guess another open. We are currently uh close to having the um open source security, Foundation vulnerability, disclosure working group.

B

um What's it called uh the vulnerability disclosure outgoing vulnerability exposure policy completed, it's been run by legal, it's I'm having a meeting with um lf's legal, again or I'm. Meeting this uh Mike Dolan uh tomorrow to discuss that document that is I will send a link to that into the chat.

G

B

This one, uh this is not entire related to this specification that we've been working on, but it's slightly related. This is the the higher level um document that describes how any um uh researcher um representing the open source, security, Foundation or any working group representing the open source security Foundation. Is it out pound?

B

Oh I'll fix the title. Thank you. Thank.

D

B

um Yes, uh uh how any research or any organization you know can report things outbound from the open source security foundation. So um that's that document um it sets a couple of guidelines that we were thinking about operating the um the.

D

B

um Specification under, in particular um the one that was kind of just did some dates.

B

um There's this expectation here that uh if we don't receive any engagement from the project, affirming their intention to fix the vulnerability within 35 days, um the open source security, Foundation reserves the right to fully publicly disclose that vulnerability. At that point, um there was a thought that that same deadline of 35 days could also be incorporated into the process for autofix.

B

So if you ask the maintainer to open uh or enable PVR on their repository and they respond- or they don't respond for 35 days um on that issue- that there may be um the possibility of of going public at that point and then also, if you do open a PVR and the maintainer doesn't respond or doesn't react within 35 days after you've opened the advisory.

B

um You could theoretically go public at that point with the or just create a public pull request at that point, because clearly the maintainers are asleep at the wheel.

B

um uh The discussion that we've been having with Michael and myself is there's been a discussion with Alpha Omega regarding an engagement with Tide lift, potentially, um where the work that we're doing where we're bulk, generating pull requests. uh There may be cases in which tide lift may stick pick up the slack around um manual disclosure um at points.

B

The problem is that that that may be possible for the open source security Foundation, um but I don't and Alpha Omega, but I don't want to put that as a requirement for all consumers of the specification right, because there may be an agreement that Alpha Omega has with Tide lift that we're paying the money for that maybe potentially, and that's not something that's possible for all any.

A

B

Take advantage of.

F

I mean I I. At the end of the day, though, the the action is the same, whether or not tidelift does it or we do it or a third-party organization or an individual.

F

Does it I I think it's still um contact the maintainer like like do do the normal, just look, the the normal private disclosure dance, um the fact that we might without committing anything we might be in a position to pay a third party to handle the last mile, maybe more efficient for us to do it, but the same work gets done, regardless of of who and I think it from this perspective, keeping it at the at the what not the who um makes it applicable to both scenarios. I think.

B

um Sorry like saying that they must engage with private disclosure if possible, not necessarily defining who that is correct, yeah, but the point of this whole engagement in this whole work is like scaling.

B

I mean great aao has more resources but scaling others as well in the research field to deploy their fixes at scale, and we I don't want to put something prohibitive in this specification. That makes that you must have resources Beyond, potentially what one individual could do in order to be complicit with this back.

E

B

You know as Alpha Omega we can go above and beyond.

F

But but I think it would not be the time to show the demo, because I I think that'll come back.

G

Exactly what could an.

F

Individual do um Okay so.

F

um Okay, I'm, assuming you can see my see my thing um so disclosure check is just a um uh it's python script. uh What it does is it goes out so, given a package, URL it'll go out to the report, the in this case Pi, Pi or npm, or wherever else it will look through uh libraries. I o it'll, if it's, if it's, if there's a backup and GitHub project it'll go there and it will essentially look for the best place to disclose vulnerabilities um in this case for Django.

F

uh Those are the best ones that it came up with and it tries to give a score of how how confident it is um for one like left pad um I think there should be a couple email addresses here found um it does look for private vulnerability, reporting being enabled on GitHub. uh It looks for tidelift, so this so in this case for left pad.

F

um You know those are. Those are the three email addresses that you know if you were to to send it. Those are probably the ones that you would find if you were looking through it manually.

F

um uh This one uh electron, Forge CLI uh happens to be covered under a kite. Lift subscription.

F

um We look for that in a couple different ways: private vulnerability, reporting is also enabled so and that's the highest um highest preference one. So what I would say is if you are a um if you're, a researcher or organization or whatever, and this was one of the things that you found something in then you could use this and and know hey. I should just go here uh to report it um output is Json as well, so you can. You can script that um there's definitely bugs not.

F

Every ecosystem is covered as well as every other one. But conceptually um does this feel like it would be helpful.

B

A

B

I think it would be helpful for me: I mean I, like I'm, not I'm. Looking at this, like not as an as an automator like this is very useful. Just for security. Research, like you know in general, um I think that one of the things that would be more help like one of the things that would be helpful, like I'm, looking at the preferred contact for the Django software Foundation right like that. One, um though that line I, would appreciate a um a. Why are you proposing this because, like, for example, the Django software Foundation?

B

Are you just looking at that? Like? Is that inside of a security.md file, or are you seeing that, like somewhere in the contributors list and like that's where it's coming from, like a a a bit more of a rationale? Yeah.

F

B

Appreciate it I.

F

Think I collect that uh so here, uh so the email address was found in the Pi Pi registry under the author field and the link to the security was found at in in the well in the dot GitHub security MD. So that's why now we could obviously make that better, but.

B

That's when it wouldn't for a security disclosure, wouldn't the priority of the one in the security dot. Md come as a higher priority than the one. That's in the pi.

F

Registry, the the problem that I have is part so I'm parsing, markdown markdown, could have like the the text could be whatever you do. Do not report to like this. You this URL, because it could be a URL. It could be uh the author's homepage. It could be hey this picture of my dog.

F

um So that's why it's it's lower I figure that the Pi Pi registry is definitely going to contact somebody on the project, um but you're right. If I could, if I felt more confident with the parsing of the markdown, maybe if there's only one email address or only one URL, that's a higher higher confidence. Sure.

B

Yeah yeah, that makes sense I was like also thinking about, like sentiment, analysis analysis of the file like you know what what is the sentiment behind this? Is this like a do not or uh yeah yeah.

B

um I think that, like this is this is super cool I. Think there's something that like I bet, I bet you Snick, like the research lab there. Github security lab like this is totally something they would have. They would want to use. I would I would throw together um I would throw suggest, throwing together a um what's. It called the uh ASCII cinema cinema demo and like like it just saying: hey, there's this thing uh great, hey, there's this thing: here's a video demo with ASCII Cinema that would actually get people using it. Okay,.

F

That I can I can totally do that um and obviously getting it installable from Pi Pi. So you can just you know: pip install Foo, um it's slightly easier right. Now, the it's just on the on the GitHub I do want to get it moved over to open ssf. That's a separate thing, but.

B

um Can you does it also support just to get regular GitHub repository URL yeah.

F

B

uh Oh okay, we'll still have the package yeah.

F

That makes sense, I think this one is, and it's also awkward because, like libraries, I o support some things. They call it ruby gems, not gem. Like does you know it's not perfect this one's interesting, because I do test it on this one, and this one um as far as I know, there's I couldn't find a programmatic way of of getting this, but I want these as bugs so that we can like manually, find it find the right author and then like implement the check to to retrieve that.

B

um Josh Josh had one that you wanted you to do in.

F

The chat, sorry I'm I'm Zoom window.

E

Ruby gems forward slash sorcery that package. It's ruby gems forward, slash sorcery.

F

Sorcery, like that, yeah.

C

F

C

G

F

No, no, so this is to GitHub. uh You know what, let's, let's do this as a as a I mean I'm not have to right now, but so ruby, gems.

C

Because you'd probably have to do some smart parsing of the readme to find it.

F

uh Which would be I mean yeah, um okay, so sorcery sorcery is the. Let me see if we.

C

Don't have to do it on the Travel hole if.

F

C

Have other topics.

D

Are great, of course, necessary.

F

I'm wondering if you know um there is this okay, so there is a security MD file here there is oh okay, so so this is a good example. The the security, the security MD file for this says email, the current maintainers. With the description of the vulnerability, you should expect a response. In 48 hours, a list of current maintainers can be found on the readme under the contacts section. So.

A

Then I would have to go to okay.

F

So, there's actually no reason why I shouldn't be able to also load the readme and look at I mean here. It's like current maintainers and there's a bullet list yeah. It should be fine, I'll I'll, pull it up.

G

C

It's also a great way for me to find out my documentation is outdated.

F

To be fair, though, the hard part so was like, as if I start parsing General readme files I'm going to get a lot of email addresses that have nothing to do with the project and being like semantically saying like say current maintainer. Or is it a current author or is it currently maintained by and not like lots.

C

Of edge cases, yeah yeah, but.

F

I think I mean all we can do is like we find some stuff that it doesn't work well on. We make it work well on it and we just rinse and repeat so cool um if you find any other bugs just dump them into the issues in the um uh in the repo and I'll just kind of one by one you know make it make it suck less.

B

B

Hello, thank you. Anybody anybody else, any any other comments before we move on.

E

Just a few on the on the chat but nice work, Michael yeah, absolutely.

B

um Cool beans hang on one second,.

A

B

B

uh Okay, so we um on to the next topic, um there is now an API for um opening private vulnerability reports via GitHub um I can pull up this that that there was an announcement about this earlier.

A

B

uh There we go. um Is there an APS, API I'm.

D

A

D

B

um So on the screen share real fast, uh so there's now an API down here create a no is it it's not yeah privately reported security vulnerability this one. So this is an API that GitHub has added that will attempt to open a private owner really report via GitHub um I'm working on the Pod GitHub bindings for this uh they've actually been finished, but they're Pi GitHub has the maintainers seem not there.

B

um So I might actually become a maintainer of that project because I use it um we'll see.

A

E

Anyways, yes, and then you can share the link. Thank you.

B

Let me actually link to the here, um but yes, it does work, uh I have used it, um uh uh and then you can also get security advisors that you've that you've opened. So as a researcher, you can use this get endpoint to view any open, pvrs that you've created, um which is also very nice um or well, that you have access to um there.

A

B

A draft endpoint that um uh is being created by there Alpha Omega we're currently in a discussion with GitHub regarding um the features that we need to allow us to open Forks via the API So. Currently, this only lets you create a private vulnerability report.

B

It does not let you also open a private fork and push changes to it, um and so, in order to fully go through the process of of reporting the vulnerability privately um and creating the fix, um we also need the ability to create the private Fork too and push the changes there.

B

um There is also a discussion with GitHub around um currently that fork name. So when you go through the process, let me do this real fast. Let me screen share again.

B

B

So right, this is I'm, not logging. Give me a second uh I need the other me my there. We are uh screen.

A

F

B

G

B

We go okay, so um uh for those of you that have not done GitHub security advisors or um you go to advisories, and this is all me testing to create advisories.

B

um But if you, so, what we're trying to do at this point is the API? Will let you, as a researcher, draft a new advisory set, a title.

B

um And then create this draft security advisory uh there things.

G

B

B

um And then the problem here is that creating a private Fork.

B

um This is an API that needs to be added by like currently, you can click it, but um then what ends up happening is this creates a repository.

B

um uh Our creates a um a a new Branch with this custom name with a unique uid. Now manoir I presume that you, when you book, pull across generate um to fix security vulnerabilities. Do you rebase those changes on a regular basis, or is it one and done.

G

So um Jonathan I'm actually traveling by park right now. It's really not the right! So I'm just listening. Can you repeat the question one more time.

B

um When you generate security fixes, do you ever rebase those changes, or is it only a one and done.

G

uh It's sometimes like there's, uh so we have only submitted what like 50 something uh Security in I. Think in those cases uh there's only like three of them, where they asked for a change in the one that we originally submitted, suggested something, and then we had to do that again, but uh yeah. So that's like less than 10 of the cases.

B

So the goal with our work is to thank you I appreciate that that's helpful.

B

um The goal with our work is to um not just generate the pull request ones, but also rebates the change regularly, so that if the maintainer um is, uh um if the maintainer is uh like non-responsive or like they take a little while like we can keep it up to date with mate, whatever the main branches um and regenerate the fix right.

B

The problem is that um this, uh because this name is uniquely generated um you there there's a problem: around storage and and memorize like knowing, like this campaign maps to this ghs ID for this repository and so we're working with GitHub to hopefully be able to get this name of this private Fork. To be um that's something that you can configure to be something um uh predictable, so that um yeah.

A

So yeah, so that so that you can run.

B

Automation against it and like be like run it and like this will be the naming convention for all these Forks and, like any tooling, that's generating pull request like the thing that that's generating the pull requests can then be separated from the thing that is um uh uh automating. The creation of the GHSA is that making sense or have I lost people.

C

Seems sane to me: okay,.

B

um So that's that's just another thing: that's being worked on right now,.

G

um And there's just two quick comments. One is that it does take a long time so that the fixes will lead to stay for a while uh before it gets eventually emerged. So in the real estate is like three months, but the other thing is the practicality of it, as in in the court case like just that part of the code base, the change can happen, but it's also unlikely.

G

So just maybe the Practical thing would be not to worry too much about it, but that's just my two cents um that people just be no problem in reducing it. It's just not gonna be a big deal, because only it's gonna be a problem. The margin issue is going to only come in if that part of the code somehow change and therefore suddenly your fix is not matching to the original one anymore, but that's uh I would say a percentage of the case as opposed to the material. Sorry, that's uh yeah.

B

We also like to keep it up to date, so that like if, for example, at the time when it was built or re, that the contribution was made like the main branch was failing right, they can, if we keep it rebased, then they can always run the latest changes and hopefully it at a future point. When we rebase it, it will be at a point where the branch is safe or clean or whatever, and so they can run the checks that they may not.

B

They want to normally run right, because the fork point is always going to be from whatever mean or head was at the time when the polar cross was generated and so being able to regenerate it at a later point is is useful.

B

um Okay, um so we were um thanks. Josh we were going through. Is there any other opens or points that anybody else wants to make before we dive back into the uh this document that we were working through.

B

Mueller all right cool, um so Mike Dolan has been through this document once I think that there's some misunderstanding from I read through some of Mike's comments and I think there's some misunderstanding about the intention of this document, so I'm going to work through that with him on on tomorrow. But let's just go through what he's requested here quickly and just through the comments that are open on this document.

B

um In these cases, the scope of the private vulnerability is often beyond what can be recently reported to each maintainer privately in a one-on-one exchange manually, oh yeah, okay, that makes sense um simply automating the creation of thousands of bug reports. It um also isn't useful. uh Okay, then Xavier said I suggest to add this doc.

B

uh I suggest to add this doc Preamble saying what to attempt before doing public disclosure via Mass PR, for example, private disclosure, when the API is available a PR that adds a detection to the project CI, for example, adding a detection for Via code, 12 or stem grab or GitHub code scanning that will alert the maintainers privately about the issue.

A

B

So this document is intended to um so uh private vulnerability just below here via the API is within the scope of this document.

C

I think, if you look at the date on one that got added to is before some of our discussions around the private disclosure.

B

All right, Josh, you came back reading this. There are two ways to interpret uh what the issue is. There are a wide variety of reporting mechanisms are inconsistent and difficult to automate. Do the variety of methods and being uncertain, which a particular project uses aim Michael scalvetta, be the mechanisms currently exist are limited when it comes to private disclosure, automating private exposure.

B

um I. Think that that the answer is both and are am I. Is this unclear and we should more clearly articulate that that those are both problems here or um yeah, I guess Josh. Can you speak more to that.

C

Yeah I think you kind of hit the nail on the head. There um they're both considerations and it might be worth making that a little bit more direct.

A

C

um Although I also wrote this like a couple weeks ago, so trying to see if it's still relevant further, that's.

D

Often impractical to.

C

Yeah so it looks like it is based off of this first part.

C

So it's impractical to privately report both because there's technical limitations doing it at scale with Automation and then also because the preferences of projects is not necessarily easy to which yes, Covetous project helps with this um know what they actually prefer.

B

Right but yes, it's like, and one of those episodes like hacker one and Bug crowd. Well, the other thing with the Packer one and Bug crowd, for example. Right is that they may have policies that are inconsistent with a vulnerability like uh open source security, research, disclosure right because a lot, a lot of vendors will have their bug betting program on hacker, one and bug and and Bug crowd. But then they'll just say: oh and now our open sources in scope, but they'll have a policy that explicitly states that hey.

B

You can't disclose this vulnerability without you know approval from the project or whatever or like some bug, Bounty term, that is not applicable to open source, but they just kind of threw it under the existing thing, because it made sense- and it was easier.

A

B

Running two programs- and now you can't submit to that program because you need to disclose because it's got a it's a vulnerability in an open source project that shifts to Downstream consumers.

C

So I guess another way to frame this would be so these are both problems. How do we want to address that with this policy.

A

C

Some of the discussions previously when it comes to the automations is basically, if it's available use it. If it's not um it's kind of up to the campaign developer, to figure out what they want to do. There am I remembering that accurately.

B

That yeah they're, like I, think we can put some like May or should in there to encourage specific behaviors. But if there is no easy way to disclose giving ultimately.

D

A

Decision-Making.

B

Process to the um to the campaign operator is the right way. Yes, I think I agree with your assessment. There.

C

Gotcha so that one I think we've more or less covered with how we've phrased that section. Maybe we can touch that up a bit. um Do.

F

C

Cover the other issue of what to do with all the different ways to contact and what, if they're, not compatible with how we want to do the disclosures.

A

B

Oh Michael I got a question for you. What what do you want to do? If Michael are you there yeah I'm here? What do you want to do? I think we discussed this maybe last week but I don't remember the answer, and maybe we should put this in here. What.

A

Do you, what do you want us to.

B

Do if they say hey, disclose wire hacker one or bug crowd or disclose my app whatever, and this is our policy, and that policy is inconsistent with a with a open source security researcher trying to fix a vulnerability that needs to get public exposed.

F

F

Just off the top of my head here, I think we should take a principled stance that because open source, because the Project's intended to be used by others that open source maintainers, if they are pressured into essentially accepting a gag order in order to disclose through hacker one that the maintainer should politely say no, either give me another mechanism. It will give me another. Please give me another mechanism. You now have 89 days.

F

You know that kind of thing where it could eventually lead to full disclosure after 90 days, because the um uh maintainer is only willing to accept things with onerous conditions on the on the researcher.

F

For example, if my, if my policy was I will accept uh you know, reports from security, researchers, just mailed me a check for a thousand dollars with the report and I'll take a look at it like that's, not a reasonable policy for me, as a maintainer to have I also think that for an open source project, um any kind of um you know signing and assigning the way. Your rights as a researcher as part of the disclosure process is not um is not reasonable.

F

I, don't think maintainer should feel that they have to like use that as the only disclosure mechanism, so they can just say nope we're going to do it. This other way, I.

D

F

It why why like, when there's a bug Bounty attached to it, that part of what you know that there is kind of an exchange of of things. But if it's just purely a disclosure thing um I, don't think there's any like good rationale for why your researchers should feel bound to that.

B

um I hadn't been told that in policy or in this specification like this.

C

My first thought would be defining what is reasonable as far as those policies on the maintainer side and then defining what you do when you encounter something that's unreasonable.

B

Yeah my my like stupid, simple solution to this problem, was hey, enable PVR all right, you're not going to enable PDR, fine, we'll just open a public pull request right like that's. That's the like simplest solution to this, but um Michael's not a fan of that plan.

B

But, like you know, truly, that's the like lowest sort of it's the lowest sort of like common denominator, where you're not you're You, by submitting via PBR you're, not agreeing to anything hopefully and right like, and you can also automate it.

C

B

C

Sense, oh sorry, go ahead! No.

F

You you, your turn.

C

Would it make sense to use the same approach that we did with the automated pvrs, where, if it's not available it's up to the campaign operator to do it, make the decision there so use the should May language.

B

Right, like you know, if the if the maintainer does not enable PDR after 35 days, you may open a public pull request at that point.

C

Yeah, so something similar where, if a maintainer only provides hacker one or bug crowd or some unreasonable disclosure method, um and they don't offer an alternative after 35 days, I, don't know just kind of spitballing some ideas there.

A

D

So the problem here is, they won't enable a private uh vulnerability disclosure and they want us to use as a researcher. They want us to use hacker one or uh one of the other bug crowd. uh Bug bounties. Is that what I'm understanding.

C

B

I think to generalize yeah, some they're they're, there's a bug crowd or hacker one or there's some and in my experience most of those usually include a like a gag policy of some kind. Even if it's like.

B

You know, just in my experience, if you read through most bug, crowd hacker one disclosure policies, they usually have some sort of gag requirement, for you know some undetermined period of time that may be infinite, or maybe until they give you explicit permission and very often is not like to a set deadline.

D

Right and then, as a researcher, you just technically have that vulnerability is constantly open because they're not doing anything with us.

B

Correct because and the risk there is, if you violate the terms of that disclosure, um you can receive a ban from hacker one or bug crowd, which means that you're no longer able to receive any sort of financial uh gains from the platform at all. So like okay, you know this is a problem with the single platform, but you're, actually exposing yourself to, for future risk of not being able to achieve any sort of financial gains from any of your research in the future.

F

It's actually really important, so so I I, while you were talking I, was looking for like is this really a thing and the first one that I came across was spotify's hacker one and.

G

F

It says you know, abide by the spot, the following Spotify disclosure guidelines, unless Spotify gives you permission, do not disclose any issues to the public or to any third party. Yes,.

B

And those are very common on hacker one and Bug crowd. It's not like they're exclusive to those platforms, but.

F

They're very common yeah.

C

So the two big concerns it sounds like is being stuck between either not being able to disclose the vulnerability to the public after a certain amount of time or presenting yourself to some sort of risk. If you do correct so violating those contracts or some other risk. Yes,.

D

C

So that might be a way to generalize it.

B

I have gotten very pedantic about this, not because I'm pedantic, but because I've have real world experience with these problems like hacker one and black crowd's triagers will get pissed at you. If you say, hey I'm, going to disclose this because it needs to be disclosed, they will throw the you agree to this when you, when you submitted this at you like they.

D

B

It's not something that they don't do they actually like. I, have reused. I've received those messages, saying hey you're, violating the terms of the disclosure of this. This program's policy.

F

I mean we could simply, you know, warning warning to security researchers. If a Project's disclosure mechanism is hacker one or we don't even need to call it hacker one. If, if it is a um be careful of the terms that you would agree to when submitting through a formal program, if that's the case, you may want to consider alternative disclosure mechanisms to get the message to the team without agreeing to such things, and that way, it's it's on the researcher to decide and from an AO perspective.

F

We may just feel that you know we won't participate in. um You know hacker one bug bounties as a result or something to to get us out of it, but maybe just the warning that there are restrictions here. If you disclose in certain ways right.

B

And so that has like that's in the disclosure, that's in the finders guide for the vulnerability exposure working group, like the guide that we published under the vulnerable disclosure group working group has that language in it, which is great, but when you're trying to automate disclosure right, you can't parse hacker ones.

B

Disclosure Paul right like at that point, if you're expecting to automate this stuff, like I, don't think it's reasonable to expect that someone will go through the process of manually, disclosing to every single one of these organizations, hacker ones.

B

Which is why the fallback is PVR or that's why my proposed solution here is PVR or public pull request right. It's if it's you're, not exposing yourself to risk and the maintainer could have reduced this if they were to be willing to engage in PVR.

F

Well, even if they do under PVR, nothing obligates the maintainer to ever make that public.

B

Correct, but we have our, you can have your own disclosure policy and you're, not agreeing to some terms of agreement and micro and and GitHub doesn't operate as I mean. You know has made a very strong point in the sand that they are not going to operate as an Arbiter between researchers and maintainers right and with GitHub and hacker one. You have um a lot of Arbiters that exist between researchers and hackers, or sorry, researchers and maintainers.

B

That we'll also use the threat of kicking you off the platform.

C

So maybe we get something in here just so, we can capture the conversation and then we can refine it.

E

Yeah I was gonna say that I'm just not sure where we would want to put that.

A

F

I mean it would be nice, so since hacker one's a uh open, a staff member, it would be nice to like, because I think this is indicative of a.

B

They can't do anything, then policies are set by their customers, hacker.

F

One is but, but if they had a structured data, they had a field that you could query reliably to say. Disclosure policy is, like you know, 90 days, public um gag forever uh or something like some something so that you're not actually parsing the text um that might it may be easier to then say you know, don't report to projects that have through hacker one to projects that have this type of uh disclosure policy.

B

um But also I, don't think that they have an automated way of actually reporting these things. I, don't think, there's an API for hackers, there's an API for receivers like that. You know if you're a manager but I, don't believe that hacker one has an API for reporting vulnerabilities.

F

Yeah, no, no uh sorry um and I I missed this email, but last week, uh Caleb reached out to me uh that uh they do have API capabilities for submitting vulnerability reports to the hacker one platform.

F

um You know how about this, since a lot of this is hacker one. Let's looping Kayla, look how the conversation there, because there's something we can do. We should try. It I think. The general warning, though here, which would apply to any reporting platform, is that you, as a security researcher, may be asked to uh give up some of your your rights when submitting a vulnerability through a platform. Beware of what you're giving up and if you don't feel comfortable, feel free to you.

F

You should think about submitting a different way, um even if that means not being able to partake in a bug, Bounty or or whatever, um and that way it's it's for the the researcher to decide where they want to go. um You know, rather than us like trying to account for all these variations.

C

Maybe we one way to fit that in and I'm not sold on the wording, but a section on Gag orders or um requests to not disclose, because that seems to be the general gist of the problem is hey for whatever reason, if you can't disclose this, how do you get around that issue?.

A

B

I guess so they do have okay bulk, create hacker asset submissions. This API employment used to submit assets to a specific program on hacker one platform when this request is successfully API will pay. That's assets, though,.

B

I, don't know what an asset enrichment report is.

B

um Okay, um I was considering putting this information like okay, so we have this down here. That's like kind of starting to replace this power disclosure. The open source software hosting provider, supports the pragmatic means of private reporting, for example, get a private reporting. Then this must be used to report the vulnerability if the pragmatic means of private reporting is not enabled on the vulnerability and a public issue requesting the private reporting feature uh be enabled on the repository organization or organization, are they or on the organization must be requested?

B

The vulnerability itself must not be disclosed, but the existence of vulnerability should be disclosed. You can't your campaign should consider how to minimize the notification load on maintainers across the projects and should consider non-promatic security policies um secured it on me, for example, as a means of preferred manual, private reporting, for example, as instead of opening many issues across multiple repositories, then the same user organization that may be appropriate for a single issue to be opened, requesting a private.

A

B

A

B

Yeah, okay and then.

F

um Sorry, the previous paragraph must be requested. Do we feel that.

B

Should be a should, no it's on mask you must you must request uh them to enable PVR.

F

um I can live with that if we just add GitHub in earlier in that sentence. So so it's clear that because I'm on gitlab, like asking it's.

B

F

uh Noodle that that's just an example, if.

B

The open source security hosting provider supports a pragmatic.

F

Oh okay, uh okay I got it okay, so lowercase private vulnerability. Okay,.

B

F

I mean we can give it: okay, no I.

B

F

B

A programmatic mean no, no, this is actually not bad programmatic gain of private reporting.

B

A

Let's just call this.

B

B

B

Fpmpr is not um enable on the Repository, uh then a public issue requesting prior uh increasing the.

B

If pmpr is available and available on the hosting, yes, that makes sense is available from from developing provider and not enabled on the vulnerable pause for a.

B

A

B

B

uh Opening an issue requesting emptr.

B

Enabled if you know this.

F

B

F

Well, so so I I I think that one's too too far up in the in the workflow. So uh second paragraph agree um okay, so so that your campaign should consider how to minimize that whole paragraph.

G

F

I feel like it's still too too: full disclosure zero day, Max.

B

May- and you can do something more than that.

F

No, no I'm thinking the the your campaign must consider how how to minimize notification well. Well, no, they shouldn't um and.

F

That second should so so your campaign should consider how and must consider non-programmatic security policy, security MD, for example, um and I- think, if all other, so if so.

B

At eye level, this isn't from a conversation that we had last week, which detailed basically that, um instead of so let's say that you have one organization with a bunch of repositories and you're going to fix them all at the same time, instead of asking each one of those individual repositories across github.com Google for each one of them to enable p uh private vulnerability reporting, you ask you open one issue in the dot GitHub repository, which has the organization level security.md file and ask there please open, please enable Pi or PVR for the entire organization.

B

Instead of opening a bunch of individual issues across the entire org.

B

Maybe that needs to get phrased better, but that's the intention.

B

It's like open one issue. Instead of opening all the issues across.

F

All the stories yeah no I'm, I'm, just imagine so so I'm so I guess we're. My. My fear is still in the objection that, like you know as a researcher you you find vulnerability in a thousand projects. You open up a thousand. You realize that none of the Thousand have PVR enabled. So you open up public issues in each of them. Saying please enable 35 days later you check you see that only 50 of them have enabled it so they so you submit 50, pvrs and 950 zero days.

B

um Yeah requests.

F

At that point and you're compliant with this policy and but I, think the the you I think the onus is not the owners, but.

F

I think I think we need to do more. I think we need to try the uh so first I I would be okay with and obviously I'm biased here but like. If the disclosure check tool is useful and and does this, then perhaps the answer is try PVR if PVR doesn't work, run the disclosure tool. If you try all of those places, none of them respond and the you.

A

B

And basically,.

F

The the code is the the maintainer like goes non-responsive for all of those things. Then. Yes,.

B

F

After 35 days,.

B

Michael Michael think think. Okay, here, okay, you mean. Let me give you a number: you have ten thousand yep.

B

What do you do with your triage tool at that point? You're you're, a learning tool at that point.

B

um Do you do you go through all ten thousand and go through and follow each one of their processes? That haven't, let's say and let's say, 9 000 of those have.

G

B

Enabled PBR.

G

F

It is crazy, expensive to do this, which is why we really we absolutely need, which is the whole reason we're talking here, is that we need to be able to to do this stuff efficiently, but in the absence of efficiency, you know it's still going back to to the you know: full disclosure zero day is the is a thing that we should all think of as the the failure mode.

F

That is just slightly better than never disclosing it, um and even if it means that we have to spend a ton of money doing manual disclosure times, ten thousand I think that's that's better, I! Think and now, if.

G

We try to do annual disclosure.

F

On 10 000 and none of them respond ever to us, then at that point you know it does flip and and the the needs of the community outweigh the needs of the maintainer and I think the full disclosure is is appropriate there, um but.

B

I, just I disagree with you on two counts. First, off most of these Pro, most open source projects across the board are somebody's one-off and doesn't don't really matter when you're looking at the scale right most projects, don't matter right. Secondly, most projects are dead.

G

Well, the white reported at all.

B

I'm sure, but like I still get I I have generated more requests back in 2019 that still get merged to this day.

C

As far as reporting stuff, that's dead, it's valuable so that folks know to avoid hey this thing's dead and it's vulnerable. Don't use.

B

It yeah that's like having an open pull request with a security fix in it is valuable, is a valuable flag to a credential user of that Library, but you'd get a CV out of it anyway, I don't no, no I, don't I, don't try to get CV numbers unless the maintainer actually says. Yes, this is a valid security vulnerability, because again the cve system doesn't want to handle it at this scale.

B

So that's why we will try to get a GHSA or a GitHub or what's uh Josh's thing, the the Global.

A

B

Right but but we're dealing with a scale that it you're, you're, still thinking small, but also assuming that everybody has money and it it you're I think that you're trying to solve this problem, assuming that there's infinite resource and infinite time, and that's that this is the entire reason that we're having this entire conversation and this entire document is existing, is you have to you have to cut your losses, a certain point for a certain vulnerability and you have to just say: you're gonna piss, some people off and it's gonna be okay, because in the grand scheme of things we fixed more security vulnerabilities and some of the stuff is not even a security vulnerability.

B

It's just a security hardening and they're just going to merge it because they don't they. They don't think it's it's not a security fix. It's a it's! It's just security hardenings. If.

F

We, if we can differentiate those two you.

B

F

I realize that the hard part is differentiating the two, but for things that are obviously security, hardening I would count that as a bug like that, it was not even in scope for this it. You know um and I think we could argue about whether like socket timeouts. Is that like denial of service, or is that a but like, but some things will obviously fall below the line or on this side or whatever and public pull requests that all day long that that's that's what it's there for.

B

um You make a trade-off between so any stat any tool. That's going to be automatic. Facing vulnerabilities like this is going to be doing static code analysis and there's a trade-off that you're making with static code analysis between fixing the vulnerability, because it looks vulnerable and missing false positives, because you're making your static code analysis tool, look for more things and narrowing it down to be more exact right now. What I did for zip slip was I said: okay, this is a code pattern that appears this is vulnerable and I.

B

Didn't look for data flow globally, I, looked at local local code bases and said this is unzipping a file and it's not sanitizing it. Okay, that could be a jar file. That's local right that, like the project built itself right, like I, can't make those assertions because data flow and control flow across a large code base is. Is it is a turing?

B

It's it's a it's a you know, it's a it's a hard problem and you can't guarantee correctness, but you can say that looks like a pattern of a common security vulnerability and even if it's not it's still a valid security hardening. So let's, let's try to fix this at scale like I, also want to be clear that most of this will be thrown at vulnerabilities that are not our CES, probably I mean at least in the beginning.

B

Now long-term goals of this is like: let's do SQL injection, but like again that's that's a it's a it's. A big um has.

A

A lot of code out there.

B

And you're you're, dealing with the the whole problem. We're trying to deal with at this point is, is a problem of scale.

B

I mean like for your point down here, like 35 days, seems aggressive and you're not giving them any other.

D

B

D

We could put something in.

A

B

That says, like you, have to warn them again at 25 days that hey they've only got 10 days left.

F

What happens if they say.

F

Got it but I I, don't I I understood, but I'm not going to enable PVR. My my security policy is security at MD. Just read that what if that is their response, how would what would the.

B

I the argument that I have is given the scale at which we are attempting to a an individual engagement. This campaign is attempting to fix a security vulnerability.

B

B

The norm for the industry, be just because of history- is that the receiver of the report dictates how the report comes in right. They publish the security of that MV file. They publish the security on txt file right and because of that, the researcher has to go through the effort of trying to find where that vulnerability needs to get recorded in order to follow their policy or they have to go like you know, Twitter DMS right like this, is an opportunity that we have as researchers to flip that script.

B

There is a norm, but that Norm has only existed because trying to track down who to report to is a hard problem right. In this case, we have a universally usable way that we can all disclose vial and it is PVR, and so when we are in the state we can dictate. Because of that, this is the way we would like to report to you. We are doing this at scale. If you don't want to follow that, it's fine you're going to get a public pull request.

G

B

We would prefer to use PVR.

F

How about this? Without because now we're jumping right down to implementation? What if you could just pipe a report file to disclosure check, so you say you.

A

Know here here's my here's, my diff.

F

Here's my markdown, here's, my whatever send that to you know all the contacts listed in the output of this. This essentially smush the two together and that way, it'll either send an email um most places, don't have like a website and a form, but you know we could we could we could deal with that? If it's PVR, then it'll do the API and do the PBR thing. If it's.

D

F

It'll, send it to security at time, left where they'll get it and do the thing um you know if you know- and this is getting back to like future talk but like if we have a separate relationship with tiger, we could just send them all to time, lift and make it really easy for ourselves. I get that this policy is not about just.

G

F

um But I think, like honestly.

D

I I think that.

F

That last uh I think it's just it's gonna.

F

It's gonna make everybody very unhappy that that last part.

B

Will this make them more unhappy, which which are you more likely to upset that going, the public disclosure route, which so far I'm only pissed off a couple? People and Apache and the rest of them have not I've not received any like negative, like what the hell are you doing like.

D

I've got a little bit.

B

Of that, but, like I, think the scale of the problem, you see there versus spamming a bunch of people with a bunch of fixes that are most often or not off, not most often sometimes, security, hardenings, and if you send them a patch file, they then have to go through the full process of downloading that patch file, applying it to their repository Yeti like they have to go through manual. Steps versus just hit a merge button right.

C

B

That you're trying to not overwhelm maintainers that are already unpaid. How.

F

About this step, one um check if PVR is enabled, if it's not enabled open up an issue say please enable PVR if you enable PPR I will submit it. You know next week or in in 20 days or whatever I will submit uh a report of a vulnerability to you through PBR. If you don't I'm, gonna, look for you in other ways and I will send you a patch file or markdown or whatever, and I will do my best.

F

That I can programmatically to get the message to you and yes, it'll be harder for you, because you'll have to do weird patch things and stuff.

F

Those are your two options and then, if I don't hear from you on either of those then 90 days later, it goes It goes public or 35 or whatever does.

B

F

um So PDR, then disclosure check then zero day.

B

So you're saying.

B

Give them the option of.

B

So open an issue if the issue doesn't, if the issue doesn't work.

B

F

Spam spam, whatever emails, we can find through disclosure track.

B

Spam, the emails- if that doesn't work yeah, then you uh okay, but then you have to run an email server or be connected to an email, server and monitoring responses.

F

uh No, you just have to reply all be to I I mean the question is: do we want that to be a no reply? Email where, like we're not looking for a back and forth engagement, we are we're doing a a one-time blast out disclosure, um it's so great. If not, then, yes, there needs to be a reply. Email address, but that's kind of what we would be doing with the private vulnerability report.

F

We would be expecting them to type in like what does this mean and for us in some way to have to respond to that. So whether you respond to that through the GitHub UI or through an email UI where.

B

You can you, can you automate like a single platform and you're having to automate from multiple different communication channels? At this point, and that's like.

F

Exploding, you know I I, honestly, I I, think that it'll be like the attempt. That'll be PVR and it'll grow over time. The vast majority of the rest will be email and it'll be a handful of like Oddities that maybe.

B

You want to write, you don't want to have anybody have to write a ticketing system, email.

F

Number, no, no, no, no, no, no, no ticketing systems.

F

We are, um we are way over time, but.

B

I really are so you so in the in the initial contact. You say: hey here's! You have 35 days. If you don't, we will report via this mechanism and we Supply the output of your tool and then, if that, if it, if it 90 days, they still have nothing, then you go public with a pull request.

F

I I think I need to think about edge cases there, but that that sounds right where we can defensively say that we've tried everything that we could short of, like human manually, like looking through every place for an indeterminate amount of time, which I don't think we should do, uh but so we've done commercially reasonable efforts to uh to find and disclose privately and either and if they aren't unresponsive, maybe if they're unresponsive completely 35 days after last contact um if they are responsive, but they just they disagree they, whatever um 90 days, uh we disclose um I, think that's I, think that's at least I mean other folks like.

A

F

You disagree but, like I feel that that's the right.

B

It's only via email right is that is that a good Line in the Sand to draw that like we will either disclose via PBR or email. You.

F

Know what I'm gonna do I'm gonna run disclosure check on the top 10 000 projects. uh It'll. Take me a couple days to run them all to see, statistically how many of them have at least one email address from the from early testing. Practically all they either have nothing, because it's debugging the tool, or they have at least one email address, so I think with that um it it should be okay,.

B

An email could be generated. Do the.

B

What's the link to your, can you send the link to your tool and we'll put that in we'll put it in the policy sure.

F

Are you once you call the school call this open, ssf disclosure check and we'll we'll rename it to that.

F

Yeah disclosure yeah that works.

B

If, after 35 days of opening an issue requesting who you are, should be enabled um impact on the maintainer, if the maintainer has been completely responsive at this point, an email should be generated to the contacts returned by the latest version of the open, SF disclosure tool.

G

B

Who will be emailed must be included in the um issue requesting the um on.

F

Yep, and that way is super clear up front.

B

What if the maintainer wants to change it? What if they say actually please email here in the in the response to the issue? Do we look at that? Do we monitor those issues and like parse them and try to like if they put a slash command? That says you know, email to.

F

We could do that that that would be easy enough to parse out if.

G

We want, if you want to define.

F

A yeah right, if you want to change this report, you know copy and update this, and, and that way it's um that I would be okay with that um I mean it makes it a little bit more complicated in our end, but I.

B

Don't think I only tell them they can override it by contributing to this Republic to your Repository.

G

F

B

um I know, but like we will be I mean like every time we run this thing. We run it with the latest version of your tool right, and so they just need to create a pull request within that 35 days.

G

B

Fix where it's going um or fix their fix, their infrastructure.

F

Add an email address to the to the security MD yeah yeah yeah.

F

um I really I really have to run. um Okay, yes,.

A

F

Like please keep this going, this is. This is really good. Yep.

G

B

Thanks everybody for going to do this in a week. Oh next, I I could do next week all right. Let's try to do this again, the next week, okay, cool thanks all.

C

Thank you guys, yeah.

A

Bye-Bye thanks through.