Closed Bug 27009 Opened 25 years ago Closed 24 years ago

jar: protocol leaves files on hard disk with predictable name

Categories

(Core :: Security, defect, P2)

Product:
Core
Component:
Security
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: norrisboyd, Assigned: security-bugs)

References

(
URL
)

Details

Opening a jar file from http has the side effect of downloading the file to the user's hard drive in a predictable location. This could be the beginning of a number of attacks that use presence on the hard drive as an indication of a more privileged source. (Java comes to mind, since the jar can contain class files.) Performing an MD5 hash to produce a practically unguessable portion of the path should fix this problem.
Group: netscapeconfidential?
Status: NEW → ASSIGNED
Target Milestone: M16
Reassign to mstoltz.
Assignee: norris → mstoltz
Status: ASSIGNED → NEW
Bulk moving all Browser Security bugs to new Security: General component. The previous Security component for Browser will be deleted.
Component: Security → Security: General
Hopefully this will be solved if/when we begin to use the network cache stream- as-file service. If we don't get to that soon, I'll solve this separately.
Status: NEW → ASSIGNED
Marking remaining exploits as beta2.
Keywords: beta2
Keywords: nsbeta2
Is this different behavior from what we had in 4.x? Putting on [nsbeta-] radar. Please let PDT know if you disagree,
Whiteboard: [nsbeta-]
Changing [nsbeta-] to read [nsbeta2-]
Whiteboard: [nsbeta-] → [nsbeta2-]
As mentioned above, this problem would go away if the jar protocol began using the network cache instead. Warren, is this still feasible? Should I mark this M20, for "some time in the future?"
Changed QA contact to Cathy.
QA Contact: junruh → czhang
=> M18
Target Milestone: M16 → M18
Assigning QA to czhang
Depends on: 24765
Keywords: nsbeta2
Whiteboard: [nsbeta2-]
Have fix, waiting on review.
Keywords: nsbeta3
Priority: P3 → P2
Whiteboard: [HAVE FIX]
Fixed. We're now using the file cache, which saves files using unpredicatble names, rather than the jarCache directory, so it is no longer possible for an attacker to place a file of known content and location on a user's drive.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Whiteboard: [HAVE FIX]
Verified on WinNT branch 10/3 build.
Status: RESOLVED → VERIFIED
Opening fixed security bugs to the public.
Group: netscapeconfidential?
You need to log in before you can comment on or make changes to this bug.