- Notifications
You must be signed in to change notification settings - Fork5
Commit0d1ecd6
committed
Reset OpenSSL randomness state in each postmaster child process.
Previously, if the postmaster initialized OpenSSL's PRNG (which it will dowhen ssl=on in postgresql.conf), the same pseudo-random state would beinherited by each forked child process. The problem is masked to aconsiderable extent if the incoming connection uses SSL encryption, butwhen it does not, identical pseudo-random state is made available tofunctions like contrib/pgcrypto. The process's PID does get mixed into anyrequested random output, but on most systems that still only results in 32Kor so distinct random sequences available across all Postgres sessions.This might allow an attacker who has database access to guess the resultsof "secure" operations happening in another session.To fix, forcibly reset the PRNG after fork(). Each child process that hasneed for random numbers from OpenSSL's generator will thereby be forced togo through OpenSSL's normal initialization sequence, which should providemuch greater variability of the sequences. There are other ways we mightdo this that would be slightly cheaper, but this approach seems the mostfuture-proof against SSL-related code changes.This has been assignedCVE-2013-1900, but since the issue and the patchhave already been publicized on pgsql-hackers, there's no point in tryingto hide this commit.Back-patch to all supported branches.Marko Kreen1 parent40e873d commit0d1ecd6
1 file changed
+10
-0
lines changedLines changed: 10 additions & 0 deletions
Original file line number | Diff line number | Diff line change | |
---|---|---|---|
| |||
17 | 17 |
| |
18 | 18 |
| |
19 | 19 |
| |
| 20 | + | |
| 21 | + | |
| 22 | + | |
20 | 23 |
| |
21 | 24 |
| |
22 | 25 |
| |
| |||
124 | 127 |
| |
125 | 128 |
| |
126 | 129 |
| |
| 130 | + | |
| 131 | + | |
| 132 | + | |
| 133 | + | |
| 134 | + | |
| 135 | + | |
| 136 | + | |
127 | 137 |
| |
128 | 138 |
| |
129 | 139 |
| |
|
0 commit comments
Comments
(0)