Noah Misch <noah@leadboat.com> writes:
> On Mon, Jul 10, 2017 at 10:46:09AM -0400, Tom Lane wrote:
>> Shall we go for broke and also remove the ASLR-disabling patch in beta2?
> As I mentioned in my message eight hours ago, no.
Ah, sorry, I'd managed to swap out that bit of info already. However,
I've now gone and read the Symantec paper you pointed to. It's pretty
interesting, although I think it should not be treated as gospel.
For one thing, it's ten years old, and for another, it's describing
the behavior of Windows Vista; one might reasonably assume that Microsoft
has improved some of this stuff since then.
I noted with particular interest that the PEB (Process Environment Block)
location is stated to be randomized whether or not you have ASLR enabled,
although apparently there are only a small number of possible locations.
I wonder whether that could explain anything. If it is affecting us
then the retry logic should fix it.
Anyway, the point at hand is Symantec's claim that there's a global
offset that normally only changes at reboot but might change at other
times. I'm inclined to take that with a really large grain of salt.
For instance, here's a flat denial of that from a Microsoft person:
https://blogs.msdn.microsoft.com/oldnewthing/20170118-00/?p=95205
with some interesting stuff in the comments too, particularly about
how Windows attempts to load DLLs at the same location in all
processes so as to share page table entries.
Looking at Symantec's appendix II, which is a script that claims to
provoke changes in this global offset, what it's doing is creating,
executing, and deleting files over and over.
It seems plausible to me that Windows intends to assign a randomized
address to an executable or DLL once per boot, or at least once per
loading of such a file, and that what Symantec's script is doing is
defeating Windows' recognition that the "same" executable is being
run each time. Without games like that, the executable image would
persist at the same base address, at least till it got swapped out,
allowing it to appear at the same address across multiple executions.
If things do work more or less like that, then it's likely that it would
have no effect on us, because the continuous existence of the postmaster
process would lock the PG executable as well as all DLLs loaded by the
postmaster into addresses that would not change for the life of the
postmaster. Under that theory, what might bite us is randomization of the
PEB, stack, or heap (which are stated to be re-done every time); or some
antivirus code that's doing something weird. It's entirely possible that
security-oriented code might take measures to ensure that it gets mapped
into different addresses in every process even though Windows wouldn't
normally do that. But all of these cases would presumably yield to retry
of the process launch.
In short, I don't really buy that we should be afraid to enable ASLR
because of this Symantec paper.
regards, tom lane
