[sqwebmail] Re: OpenBSD 3.2 breaks Courier, Qmail.

[Sam Varshavchik]

[EMAIL PROTECTED] writes:

Well, if microseconds are added to the message's filename, then the following must now happen in order to have duplicate filenames:

But later you address the clock sync problem when NFS is used...

That's only a factor that negates the check in qmail-pop3d, that's all.

Would not it be simpler, and surer if qmail-local looks into cur as
well, and backs off for 2 seconds if it sees a namecollision?

And exactly what would qmail-local look for, in cur? Should it stat a list of filenames that enumerate every possible combination of message flags? Or should it just read the entire directory, looking for a message with the same base filename?

The more I consider this, the more I believe that microseconds should be added to the filename, unless the kernel provides assurances that the same pid won't be recycled within the same second.

****

From: Henning Brauer <[EMAIL PROTECTED]>
Subject: Re: OpenBSD 3.2 breaks Courier, Qmail.
Date: Wed, 15 Jan 2003 00:56:50 +0100

In other words: not bloody likely. CPU cache, you say? Still not going to cut it. No way, no how.

you don't get the point. there is no guarantee.

I just explained, in detail, what must happen in order to still expose the race. And I showed that this is mathematical impossibility with current hardware, and any hardware in the foreseeable future.

You still maintain otherwise, so I am curious as to what hardware you are using. That must be some real impressive memory bandwidth you got there.

You must be using a quantum computer. I see no other explanation. Ok, I'll add it to the README: "Courier does not work on OpenBSD running on a quantum computer."

>Then it is broken.
>I question you above statement. We ship with random PIDs since 6 years or >so now.

What exactly do "random PIDs" have anything to do with anything? "Random PIDs" does not necessarily preclude pids from not being recycled within a short timeframe. In fact, I can easily think of ways to generate random pids, but prevent pids from being recycled in the same second. So one does not preclude the other.

irrelevant.
there was never a guarantee that pids aren't reassigned within a certain

As I just mentioned, random pids do not mandate that the pids must be recycled within the same second, and I explained why. You completely ignore that point, and still prefer to get stuck on the claim that there was never a guarantee of some sorts.

See, try to wrap your brain around the concept that these are two completely separate issues. I would even argue that not recycling the same pids so soon in fact _improves_ security. And isn't that what your goal is, after all? Your blind insistance on ignoring this point is somewhat puzzling...

>predictable PIDs are a problem.
I'd appreciate a brief outline of what the inherent problem with predictable PIDs, and only predictable PIDs is, which does not exist if pid generation is not predictable. I'm mystified.

please look up this yourself; enough has been written on this topic; too
much to be repeated here.

Really? I tried, but couldn't come up with any situation where a predictable pid enables an exploit that could not exist without predictable pids. Perhaps you could be helpful and share a short example.

But that's still is getting off topic. As I just said, having unpredictable pids does mean that individual pids must be allowed to recycle so quickly; and taking the appropriate measure to do seems to actually improve the alleged goal of unpredictable pids. So, your insistance to the contrary is rather puzzling.

Of course every pid is reassigned eventually. The thing is that if you see a process with pid 300, and you see a process with pid 300 a second later, then you should be fairly confident that this is the same process.

no.
there never has been such a guarantee.
your assumption is flawed.

Ok, then would you be kind enough to explain what the purpose of the ps(1) command is for, then? Taking your assertion to its next logical step means that ps(1) can randomly re-sort the PID column, and its output could still be valid, because, after all, a brief period of time after its output completes (with the period of time being more precisely defined by Planck's constant) the same pids can now be assigned to different processes.

Wow. Moore's law sure changed things a lot, of the past couple of years...