Closed Bug 296270 Opened 20 years ago Closed 20 years ago

Default user agent on AIX contains machine information

Categories

(Core :: Networking: HTTP, defect)

Other
AIX
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: pkwarren, Assigned: pkwarren)

Details

(Keywords: fixed-aviary1.0.5, fixed1.7.9, privacy, Whiteboard: [sg:nse])

Attachments

(1 file)

On AIX, the default user agent is constructed in the following manner: struct utsname name; int ret = uname(&name); if (ret >= 0) { nsCString buf; buf = (char*)name.sysname; buf += ' '; buf += (char*)name.machine; mOscpu.Assign(buf); } On AIX, the values in the utsname structure are different than on other Unix platforms. For example, these are the contents of the uname array on AIX: $ ./aix-uname uname.sysname: AIX uname.nodename: ut uname.release: 1 uname.version: 5 uname.machine: 000D214D4C00 The unfortunate problem with this bug, is that the default user agent on AIX platforms is set to a value which can be unique to the machine, which presents a possible privacy issue. I propose that this be changed on AIX to be: buf = uname.sysname; buf += ' '; buf += uname.version; buf += '.'; buf += uname.release; I will add a patch to this bug which makes this change.
Attached patch Patch v1Splinter Review
Assignee: darin → pkwarren
Status: NEW → ASSIGNED
Attachment #185062 - Flags: superreview?(darin)
Attachment #185062 - Flags: review?(mozilla)
Attachment #185062 - Flags: approval1.7.9?
Attachment #185062 - Flags: approval-aviary1.0.5?
http://lxr.mozilla.org/classic/source/cmd/xfe/mozilla.c#1992 contains similar logic from the classic Mozilla source code.
Comment on attachment 185062 [details] [diff] [review] Patch v1 r=mkaply with a comment that says why.
Attachment #185062 - Flags: review?(mozilla)
Attachment #185062 - Flags: review+
Attachment #185062 - Flags: approval1.7.9?
Attachment #185062 - Flags: approval1.7.9+
Attachment #185062 - Flags: approval-aviary1.0.5?
Attachment #185062 - Flags: approval-aviary1.0.5+
Attachment #185062 - Flags: superreview?(darin) → superreview+
are the casts needed, btw? (and, does this really need to be security sensitive?)
I think the casts are there for historical reasons. There may be some platforms that return "unsigned char" maybe?
Does this need to be marked security sensitive? It's a minor privacy issue, not an exploit.
Keywords: privacy
Whiteboard: [sg:nse]
Group: security
Attachment #185062 - Flags: approval1.8b3?
Attachment #185062 - Flags: approval1.8b3? → approval1.8b3+
Fixed on trunk. Checking in nsHttpHandler.cpp; /cvsroot/mozilla/netwerk/protocol/http/src/nsHttpHandler.cpp,v <-- nsHttpHandler.cpp new revision: 1.112; previous revision: 1.111 done
Fixed on 1.7 branch. Checking in nsHttpHandler.cpp; /cvsroot/mozilla/netwerk/protocol/http/src/nsHttpHandler.cpp,v <-- nsHttpHandler.cpp new revision: 1.94.2.4; previous revision: 1.94.2.3 done
Keywords: fixed1.7.9
Fixed on aviary branch. Checking in nsHttpHandler.cpp; /cvsroot/mozilla/netwerk/protocol/http/src/nsHttpHandler.cpp,v <-- nsHttpHandler.cpp new revision: 1.94.2.1.2.3.2.1; previous revision: 1.94.2.1.2.3 done
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Verified fix in a trunk build from today.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: