[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+aC4ksAirMkOW5R1p=YzQH6R3gOBJZsiB2YqjH+sB+by2--pw@mail.gmail.com>
Date: Wed, 24 May 2023 07:26:42 -0700
From: Anthony Liguori <anthony@...emonkey.ws>
To: oss-security@...ts.openwall.com
Subject: Re: Clarification on embargoed testing in a partner cloud
I'm sending from my personal account for convenience but in case anyone
doesn't know, I work at AWS and am on the private list for Amazon Linux.
On Wed, May 24, 2023 at 6:43 AM Solar Designer <solar@...nwall.com> wrote:
> On Wed, May 24, 2023 at 10:45:15AM +0200, Moritz Muhlenhoff wrote:
> > Am Thu, May 11, 2023 at 01:57:04PM +0200 schrieb Marcus Meissner:
> > >
> > > I understand that while some of the operators of the public clouds are
> also on
> > > the distro lists, these are parts of very large cooperations and not
> the same
> > > team as the intake PSIRT subscribed to distros.
> > >
> > > So from my point I would suggest to exclude testing on third party
> public clouds.
> >
> > I agree, FWIW.
>
> Thank you. So far, we have Marc's request for clarification (which
> didn't express an opinion/preference) and two "suggest[ions] to exclude
> testing on third party public clouds" above. I also suggest the same,
> yet I am not sure whether/how to make that part of the policy. It is
> non-obvious whether/where/how to draw the line between (disallowed)
> sharing and mere (allowed) usage of third-party/rented resources.
>
> If we explicitly disallow "testing on third party public clouds", then
> what about testing on rented dedicated servers (which are often also
> centrally managed through the provider's infrastructure), or on own
> servers in rented racks in third-party datacenters (where the datacenter
> staff has physical access), etc. And then there's communication over
> third-party Internet infrastructure, whereas our policy currently
> doesn't mandate usage of encryption except for messages from the list to
> its immediate subscribers.
>
I don't think this is the right policy. First, I don't think that terms
like 'cloud' or even 'colo' are at all well defined. I can setup a website
and rent the Raspberry Pi rack next to my desk as a 'Cloud' but that's
wildly different from something like AWS.
Likewise, colo's vary tremendously in quality of security. You have places
like Switch in the US that have crazy security including armed guards.
I've also visited colo's that are glorified closets with extremely poor
physical security.
I think the right policy for list members is that they are responsible for
understanding the third-party infrastructure they use and if they aren't
confident that they can maintain the rules of the list, they shouldn't use
it.
For list members that have questions about AWS, I'm happy to answer, in
gory details. I know other large cloud providers have folks on the list
that would likely offer the same (or at least direct to the appropriate
people). I can also help make connections to most of the large cloud
providers if folks don't have contacts.
That said, I don't think this is the most important part of the
discussion...
> Also, I guess these days there are distros that are primarily built in
> the cloud yet are not projects of the cloud providers - e.g., projects
> of startups that got free cloud credits, as well as those that like the
> flexibility and not needing to manage physical servers themselves. If
> one of those wants to join the distros list, do we reject them and
> require that they setup security build/testing, private issue tracking,
> e-mail infrastructure out of cloud first, or do we accept (if they meet
> all other criteria)? So far, we didn't even ask new members whether
> they possibly build/test/track in the cloud, and maybe we already have
> some that do.
>
Building/testing involves a lot of things. Testing binary artifacts is
IMHO very low risk. If an attacker gets a binary but has no additional
information about a vulnerability, the time and effort it takes to reverse
engineer what's changed and find the vulnerability is pretty darn high.
The strict embargo period of the list here is a big mitigation factor. By
the time most folks get to this stage, there is maybe a week left in the
embargo. IOW, I think scp'ing a binary to a testing box in more or less
any environment is pretty low risk due to the difficulty of extracting
information.
OTOH, most vendors ship around RPMs and RPMs contain changelogs. Do they
change logs contain CVE numbers only or do they describe the CVE in gory
detail? This ends up mattering a lot.
And there's a big difference between scp'ing a binary to an instance versus
publishing a yum repository. Repositories tend to have broad permissions.
Is the repo access controlled to include folks outside the strict
need-to-know in your organization? Are you also publishing source packages
as part of this process?
I think this line of questioning is probably more relevant for folks on
this list.
Regards,
Anthony Liguori
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
