Closed
Bug 406290
Opened 17 years ago
Closed 17 years ago
Potential read of uninitialized data in cert viewer
Categories
(Core :: Security: PSM, defect, P2)
Tracking
()
RESOLVED
FIXED
People
(Reporter: KaiE, Assigned: KaiE)
Details
(Keywords: crash, fixed1.8.1.12, Whiteboard: [sg:moderate?])
Attachments
(2 files, 1 obsolete file)
1.75 KB,
patch
|
wtc
:
review+
|
Details | Diff | Splinter Review |
1.74 KB,
patch
|
KaiE
:
review+
dveditz
:
approval1.8.1.12+
beltzner
:
approval1.9+
|
Details | Diff | Splinter Review |
File mozilla/security/manager/ssl/src/nsNSSCertHelper.cpp ProcessGeneralName calls into PR_NetAddrToString (twice). The return value from PR_NetAddrToString it not being checked. Even if PR_NetAddrToString fails, the code will the contents of "buf" to a string. "buf" is uninitialized and might not contain zero.
Assignee | ||
Comment 1•17 years ago
|
||
Firefox 2 has the some code, setting to 1.8 branch.
Version: Trunk → 1.8 Branch
Comment 2•17 years ago
|
||
PR_NetAddrToString is unlikely to fail there, but we should check its return value. What should we do if PR_NetAddrToString fails? Store an empty string in "buf", or just call ProcessRawBytes? The latter seems better. Since we're in a switch statement, we can do that using "break" if PR_NetAddrToString succeeds: if (current->name.other.len == 4) { addr.inet.family = PR_AF_INET; memcpy(&addr.inet.ip, current->name.other.data, current->name.other.len); if (PR_NetAddrToString(&addr, buf, sizeof(buf)) == PR_SUCCESS) { value.AssignASCII(buf); break; } } else if (current->name.other.len == 16) { addr.ipv6.family = PR_AF_INET6; addr.ipv6.flowinfo = 0; memcpy(&addr.ipv6.ip, current->name.other.data, current->name.other.len); addr.ipv6.scope_id = 0; if (PR_NetAddrToString(&addr, buf, sizeof(buf)) == PR_SUCCESS) { value.AssignASCII(buf); break; } } /* invalid IP address */ ProcessRawBytes(nssComponent, ¤t->name.other, value); break; Note that in the IPv6 case I added two lines to set "flowinfo" and "scope_id" to 0. Alternatively you can just zero the whole "addr" at the beginning: memset(&addr, 0, sizeof(addr));
Assignee | ||
Comment 3•17 years ago
|
||
Wan-Teh, thanks a lot for your helpful comments! > What should we do if PR_NetAddrToString fails? Store an empty string in > "buf", or just call ProcessRawBytes? > The latter seems better. I agree. > Note that in the IPv6 case I added two lines to set "flowinfo" > and "scope_id" to 0. Alternatively you can just zero the > whole "addr" at the beginning: > > memset(&addr, 0, sizeof(addr)); If there are mutliple members that need to be initialized in order to make the conversion work, I rather prefer the memset. > Since we're in a switch statement, we can do that using "break" I tend to avoid jumps, in the patch I use a status variable to avoid it.
Attachment #293033 -
Flags: review?(wtc)
Assignee | ||
Comment 4•17 years ago
|
||
I should compile my patches before I attach them... Changed SECStatus to PRStatus.
Attachment #293033 -
Attachment is obsolete: true
Attachment #293035 -
Flags: review?(wtc)
Attachment #293033 -
Flags: review?(wtc)
Comment 5•17 years ago
|
||
Comment on attachment 293035 [details] [diff] [review] Patch v2 r=wtc. The local variable name "IPStatus" should be spelled in lowercase. Perhaps just "status"?
Attachment #293035 -
Flags: review?(wtc) → review+
Assignee | ||
Comment 6•17 years ago
|
||
Requesting blocker status for this crasher bug, patch in hand.
Flags: blocking1.9?
Assignee | ||
Comment 7•17 years ago
|
||
Wan-Teh, thanks for your review. I renamed the variable as you suggested. No other changes in this patch, carrying forward r+.
Attachment #293144 -
Flags: review+
Attachment #293144 -
Flags: approval1.9?
Updated•17 years ago
|
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Comment 8•17 years ago
|
||
Comment on attachment 293144 [details] [diff] [review] Patch v2 + variable renamed a=beltzner
Attachment #293144 -
Flags: approval1.9? → approval1.9+
Assignee | ||
Comment 9•17 years ago
|
||
fixed
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Comment 10•17 years ago
|
||
We want this on the 1.8 branch you said, right? Please request approval on this patch if it applies, otherwise on a new branch patch.
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.12?
Whiteboard: [sg:??]
Assignee | ||
Comment 11•17 years ago
|
||
Comment on attachment 293144 [details] [diff] [review] Patch v2 + variable renamed Dan, thanks for catching. Requesting approval.
Attachment #293144 -
Flags: approval1.8.1.12?
Updated•17 years ago
|
Flags: blocking1.8.1.12? → blocking1.8.1.12+
Whiteboard: [sg:??] → [sg:moderate?]
Comment 12•17 years ago
|
||
Is there a testcase for this? I guess we can run in a debug build with uninitialized variable checking, or maybe something like gflags.exe on windows will check that.
Comment 13•17 years ago
|
||
Comment on attachment 293144 [details] [diff] [review] Patch v2 + variable renamed approved for 1.8.1.12, a=dveditz for release-drivers
Attachment #293144 -
Flags: approval1.8.1.12? → approval1.8.1.12+
Comment 15•17 years ago
|
||
QA isn't sure how to verify this fix. Dveditz, did you get any more information?
Updated•16 years ago
|
Group: security
Comment 16•16 years ago
|
||
Comment on attachment 293144 [details] [diff] [review] Patch v2 + variable renamed Al: just verify that this patch has been checked in on the MOZILLA_1_8_BRANCH. It is not easy to verify that we're not using the buffer 'buf' uninitialized by testing.
You need to log in
before you can comment on or make changes to this bug.
Description
•