freebsd security - Jul 2019 - Review of FreeBSD Security Advisory Process: Incl Heads Up, Dates, Etc [cont: 5599 SACK}

On 2019-Jul-04 00:06:10 -0400, grarpamp <grarpamp at gmail.com>
wrote:
>Continued from beginnings in:
>https://lists.freebsd.org/pipermail/freebsd-security/2019-June/009996.html
>
>> I don't generally document a timeline of events from our side.
>
>There would be benefit to further transparency with
>some new data fields in FreeBSD advisories,
>leading to metrics analysis by userbase and project,
>appropriate resource allocation efficacies, etc.
Security Officer is a volunteer position and their time is valuable.
What benefits would be gained by requiring them to do more work to
provide information that is mostly already available elsewhere?
>Date_Discovered: Date of original discovery by discoverer.
This will be in the linked CVE.
>Date_Received: Date project received notification (or
>observed any info), regardless from external or internal source.
How/why is this relevant?  I agree that the project has been ignored
in some cases but that is generally discussed separately.
>Issue should also be posted heads up to lists at this Received
>time.
Definitely not.  Early advice of vulnerabilities is very much "need to
know".
Unless someone's expertise is required to rectify the vulnerability, details
regarding the vulnerability should remain private.  The discoverers may
choose to publish early information, in which case, the Project may choose
to publicly reference that information.
>Also ends up being a bit more efficient as fewer cycles need spent
>on deciding and managing what to witholding timing sched contracts,
>under whatever questionable premises readily found searching
>net from thread above. To the extent any of this have possibly
>applied in the past.
Public announcement dates are generally not under Project control - where a
vulnerability affects multiple vendors, there is almost always general
agreement on a common announcement date.  If the Project leaks information
about unannounced vulnerabilities, it will stop receiving advance
information about vulnerabilities - this definitely will adversely impact
the Project.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL:
<http://lists.freebsd.org/pipermail/freebsd-security/attachments/20190705/86c51922/attachment.sig>

On 7/5/19, Peter Jeremy <peter at rulingia.com>
wrote:
> On 2019-Jul-04 00:06:10 -0400, grarpamp <grarpamp at gmail.com>
wrote:
>>Continued from beginnings in:
>>https://lists.freebsd.org/pipermail/freebsd-security/2019-June/009996.html
> What benefits would be gained by
Some have been, and more can be by others,
outlined in the ongoing threads.
> Security Officer is a volunteer position and their time is valuable.
> requiring them to do more work to provide information
Date_Received adding is not "more work" in any real sense.
FreeBSD Project knows when it becomes aware of an issue,
readily available in the very same email headers, forum post
headers, etc... a minute's cut and paste into an Advisory.

That's an easy first step.
> that is mostly already available elsewhere?
In the Subject example, and many others, no.
Discovered and Received dates are often not given.
>>Date_Discovered: Date of original discovery by discoverer.
> This will be in the linked CVE.
It is not present in the current CVE or Netflix or FreeBSD infosheets.

If some external discoverer wants to play silly and coy
with that Date_Discovered info, fine.

However once Date_Received occurs as above,
FreeBSD project should be denoting its Date_Received.

>>Date_Received: Date project received notification (or
>>observed any info), regardless from external or internal source.
>
> How/why is this relevant?
Already explained... it is critical datapoint for user base to review
evaluate community allocation of resources to appropriate levels of
security response. They might choose months, weeks, days. But
without Date_Received, everyone is left in dark, and allocations
potentially not wherever they should be to meet general needs.
> I agree that the project has been ignored
> in some cases but that is generally discussed separately.
FreeBSD ignored by external fake security purveyors?
If that is the meaning, that would be a good thing,
hopefully due to FreeBSD doing things toward real
security that counter that.

>>Issue should also be posted heads up to lists at this Received
>>time.
>
> Definitely not.  Early advice of vulnerabilities is very much "need to
> know".
Utterly False. If you are the owner... user, admin, entity or even
customer with data or services running on... a vulnerable system,
it is absolutely without question your need to know.

Further, if FreeBSD is not posting a heads up upon its Date_Received
of what it knows so far, it is putting itself in very questionable position
of claiming to knowing best for all when in fact it does not even know
for one, instead of rightly setting those decisions off to systems owners
as best suits their own needs via heads up post.
> Unless someone's expertise is required to rectify the vulnerability,
> details regarding the vulnerability should remain private.
What external does is up to them.
Yet as herein, once it hits FreeBSD's doorstep, FreeBSD's
responsibility is to users first and foremost to point of exclusivly.
> The discoverers may
> choose to publish early information
As above, that's upon them and their cred game.
Not forgetting that those discoverers that withold often
get caught and look silly.
> in which case, the Project may choose
> to publicly reference that information.
If FreeBSD is independant, it can refer and publish
whatever it knows, when it knows it.

If it is not, then those aspects of FreeBSD need very serious
opening up to sunlight and review by the entire community.

Same if FreeBSD were subject to "Donation Capture",
that would need reviewed extremely closely.
> Public announcement dates are generally not under Project control - where a
> vulnerability affects multiple vendors, there is almost always general
> agreement on a common announcement date.
This is a game, a fake news show meant to make the interviewees
look good, typically monied vendors of closed proprietary garbage
smelly swiss cheese product, everyone knows it, so just stop.
> If the Project leaks information
> about unannounced vulnerabilities, it will stop receiving advance
> information about vulnerabilities - this definitely will adversely impact
> the Project.
If FreeBSD is or wants to playing the [vendor] game, wants to become
a closed system, subject to such others, etc... it will never be known
for pushing the much needed opensource HW and SW philosophy
envelope any further ahead into the light through its openness action
or even activism. There are enough closed models out there already.

Don't let those closed actors fool and play you into their dark traps.

FreeBSD hopefully is, and must be, better than that.



Here's another example of secrecy serving no one other
than dark forces (in this case, literally TLA's and nefarious
actors around the world against owners users customers)...

https://zerodium.com/program.html

FreeBSD LPE is only worth $50,000, that's less than Windows.
One can of course discuss in a separate thread the LoC vs
Funds vs Usercount vs Fruits of Vuln therein.

The the question of what great results from if FreeBSD community
and or foundation funds just one fulltime dedicated security reviewer
at $50k/yr...
and how that news and results might generate more donations in turn...


>> Does FreeBSD publish its vulnerability response process documentation?
>> If not, would FreeBSD be open to such transparency?
> You?re asking volunteers, performing a very time-consuming task, to do even
more work.
That would be another great first step.
And it's easily done and opened to entire community contribution
via the Wiki, such that works doesn't have to come down to
just N existing volunteers.



Part of doing things such as these in the open, a wiki list of oppurtunities,
processes, etc is that it allows you to call for participants,
new volunteers, people can drop by and see what interests them,
can evaluate if they would like to add resources to gain from that
investment [in their own system] in turn, etc.