YUM security issues...

Justin Cappos justinc at cs.washington.edu
Wed Jul 30 15:42:44 UTC 2008


You might also think about requiring the mirror's IP address to fall
in the subnet (or else they ask for your approval).   This might
further complicate an attacker using this for evil.

Thank you for providing this information...
Justin

On Wed, Jul 30, 2008 at 4:59 AM, Josh Bressers <bressers at redhat.com> wrote:
> On 29 July 2008, "Domsch, Matt" wrote:
>> On Tue, Jul 29, 2008 at 11:35:03AM -0500, Justin Cappos wrote:
>> >    I was wondering if any changes have been made or are planned for
>> >    MirrorManager (i.e. preventing mirrors from arbitrary grabbing parts
>> >    of the address space).   We're submitting the final version of our
>> >    paper soon (the version that will appear in print) and I'd like to
>> >    include any updates about this.
>>
>> As for "arbitrary grabbing of address space", I'm open to ideas.
>> Perhaps a /16 is too large for "anyone" to be able to grab - e.g. could
>> should limit the auto-granted size by some amount.  However, it
>> doesn't eliminate the concern.  If Mallory wants to attack
>> specifically Alice, he only need know the addresses Alice is likely to
>> be coming from and add those in, even one-at-a-time.
>>
>> Restricting to a /16 seemed reasonable to me.  A good balance of "big
>> enough to be useful", yet small enough that it can't affect too many
>> people.  Larger allocations are available on request, by showing some
>> form of ARIN assignment.  Still, one could request such and run a
>> mirror inside that assignment that is still malicious.  And I'm not
>> willing to throw out this very useful feature, for fear someone could
>> use it for evil.
>>
>
> I think this is fine, and even desirable in most instances.  As long as yum
> will try the next mirror in the list if the primary one is outdated, this
> becomes a non issue.
>
> If anything, I'd suggest you advertise this feature more.  I had no idea
> MirrorManager could do this, and I suspect there are a number of
> organizations that could benefit from knowing this.
>
> Thanks.
>
> --
>    JB
>




More information about the Fedora-infrastructure-list mailing list