CentOS/RHEL packages for - Shibboleth Service Provider Security Advisory [27 February 2018]

[Andy Fleming]

 Is anyone else having trouble getting the packages from the repos for
RHEL/CentOS?

http://download.opensuse.org/repositories/security%3A/
shibboleth/CentOS_7/x86_64/xmltooling-schemas-1.6.4-3.1.x86_64.rpm: [Errno
12] Timeout on http://provo-mirror.opensuse.org/repositories/security:/
shibboleth/CentOS_7/x86_64/xmltooling-schemas-1.6.4-3.1.x86_64.rpm: (28,
'Operation too slow. Less than 1000 bytes/sec transferred the last 30
seconds')
Trying other mirror.

I've been getting these sorts of timeout errors on both EL6 and EL7 systems
since the packages were released.  Yum sees that there are updates, but
never can get them downloaded.  Even cleared the yum cache.  Just asking if
there is a know problem with the repos before I start manually downloading
and installing them.


Sincerely,
Andy Fleming
Systems Engineer
[image: KanREN] <http://www.kanren.net/>
[image: phone] 785-856-9820
2029 Becker Drive, Suite 282
Lawrence, Kansas 66047
[image: linkedin]
<https://www.linkedin.com/company/92399?trk=tyah&trkInfo=clickedVertical%3Acompany%2CclickedEntityId%3A92399%2Cidx%3A1-1-1%2CtarId%3A1440002635645%2Ctas%3AKanREN>
 [image: twitter] <https://twitter.com/TheKanREN> [image: twitter]
<http://www.kanren.net/feed/> need support? <support at kanren.net>

On Tue, Feb 27, 2018 at 9:00 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> I'm taking the unusual step of adding a follow up announcement on this for
> a couple of reasons. Firstly, it's not solely a Shibboleth bug and there's
> a blog article from the Duo researcher now that people should know about.
> [1]
>
> Secondly, the implications here may not be clear, so I want to reinforce
> this: people have not found all the implementations that are vulnerable to
> this bug and its siblings. CERT reached out to many, but they can't hit
> everybody, and they naturally omitted a whole lot of the one-off stacks out
> there used by cloud vendors which many in this community use Shibboleth
> routinely to integrate.
>
> As part of my nature study for this process, I investigated, discreetly, a
> number of SPs that my university has campus-wide integrations with and that
> did not support XML Encryption. This is the sweet spot for the bug, because
> truncation attacks generally require overlapping user identifiers, and
> 150,000 identities provides that kind of thing.
>
> Out of about 6 I checked, 4 were vulnerable and none of them likely know
> about this yet. I've started my own campus process of reporting the issues
> and turning the long crank of getting the vendors aware of them.
> Unfortunately, this is a process that many of us are going to have to spend
> time on.
>
> Some of them were vulnerable to the previous bug we fixed last month, and
> I also am not even sure that Duo understands the full range of potential
> flaws here because I found successful attacks that were similar to, but not
> the same as, the one they formally reported. This is going to be a process.
>
> Again, focus on the unencrypted integrations. I would also urge all of us
> to begin to insist on the use of XML Encryption going forward. We will also
> need to begin the long process of forcing implementations to get compliant
> with AES-GCM encryption, which will be the default in Shibboleth V4, and
> which replaces the long-broken AES-CBC encryption used almost universally
> in SAML today. It's time to fix that.
>
> -- Scott
>
> [1] https://duo.com/blog/duo-finds-saml-vulnerabilities-
> affecting-multiple-implementations
>
>
> --
> To unsubscribe from this list send an email to announce-unsubscribe@
> shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180305/337709f4/attachment.html>