Walt Mankowski via plug on 4 Jan 2022 06:35:39 -0800

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Microsoft Exchange year 2022 bug in FIP-FS breaks email delivery

On Tue, Jan 04, 2022 at 09:15:07AM -0500, Rich Freeman via plug wrote:
> On Tue, Jan 4, 2022 at 6:09 AM Walt Mankowski via plug
> <plug@lists.phillylinux.org> wrote:
> >
> > Arstechnica had a report on this bug yesterday, and it's an even worse
> > bug than the original report made it seem. Turns out that 32-bit
> > number wasn't being used for the date, but as a version number where
> > the first 2 digits were the year! And they pushed it out on New Year's Eve!
> >
> Looking at the article it sounds like the version numbers were based
> in part on a date.  As in "debian-archive-keyring_2021.1.1" or
> "wireguard-tools-1.0.20210424".  That isn't too uncommon (those are
> both real-world examples).

Sure, it's a very common practice. What's not common is storing the
date the way they were. It's ludicrous.

> Pushing out daily updates on New Year's Eve doesn't seem too
> unreasonable.  It sounds like these are spam detection signatures.
> Unless spammers are going to take off on holidays I can't imagine that
> you're going to want to stop updating your filters on holidays.

I don't see anything in the article that says these were daily
updates. If not, then pushing them on a Friday, not to mention a day
that's a holiday for most people, seems like a really poor idea. It's
hard to imagine any spam being so bad that an update couldn't have
waited until Monday.

> If this is a version number then it sounds like they don't actually
> need to do any kind of date processing on it - the number probably
> exists mainly to determine if an update should be applied or not.  So,
> a numeric type probably isn't a big problem.  I'd still object to the
> two-digit year and of course anytime you use a numeric type you need
> to give thought to the largest value you will be storing.

It looks like they can keep using their new numbering scheme for the
time being until it gets fixed. But now that I see how they were
storing dates, it seems even worse than the initial report. I have so
many questions:

* How did they not know there's a limit to the size of a signed 32 bit

* Given how it was used, why wasn't it at least an unsigned int?

* Why didn't they use 64 bit ints?

* How did this ever pass code review?


Attachment: signature.asc
Description: PGP signature

Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug