checkuser reports wrong device for login events
Closed, InvalidPublicSecurity
Actions

Assigned To

None

Authored By

	RoySmith
	Sep 14 2024, 3:51 PM

Description

I'm marking this as a security bug because it's checkuser-related. Feel free to remove the security tag if appropriate; there's no user-identifiable information that I care about in any of the CU extracts I've included.

I've been watching T372702 and trying to collect data for it by running checkuser on myself when I find myself logged out per the behavior described in that phab ticket. I use two devices at home. One is a Mac Mini M2, which logs as:

Brand: Not;A=Brand 24.0.0.0, Brand: Chromium 128.0.6613.120, Brand: Google Chrome 128.0.6613.120, Platform: macOS 14.5.0, Architecture: arm, Mobile: No

The other is an old Macbook Pro, which shows up as:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36

Earlier today, I was using the laptop, then I sat down at my desktop (the Mac Mini) and discovered I was logged out of enwiki. So I logged back in and ran checkuser on myself. What I got was:

2024-09-14
logs  15:21:49  RoySmith talk contribs block check Previously blocked Autopatrolled, Checkusers, Administrators Successfully logged in to Wikipedia as RoySmith
IP: xx.xx.xx.xx   Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36

WTF? That login was performed on the arm mini but got logged as if it happened on the Intel laptop!

Details

Risk Rating: Low
Author Affiliation: Wikimedia Communities

Related Objects

Mentioned Here: T345818: Store client hint mapping rows for login events
T372702: editors are repeatedly getting logged out (August 2024)

Event Timeline

RoySmith created this task.Sep 14 2024, 3:51 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 14 2024, 3:51 PM

RoySmith added a project: CheckUser.Sep 14 2024, 3:52 PM

RoySmith added a subscriber: Dreamy_Jazz.

Johannnes89 subscribed.Sep 14 2024, 5:07 PM

sbassett added a project: Trust and Safety Product Team.Sep 16 2024, 3:15 PM

sbassett edited projects, added SecTeam-Processed; removed Security-Team.

As long as you are okay with the user agent data being public, I think this does not need to be protected as a security bug.

My feeling is that this is related to Google-Chrome-User-Agent-Deprecation (as the browser is chrome). I think this because it could be Chrome hiding more of the browser, device and operating system information from the User-Agent header. Therefore, it is not really a bug in CheckUser as it is storing the user agent string as it is sent from the browser.

This probably is an indication that collecting http-client-hints data on actions other than editing is more important (if the obfuscation in the header is getting worse). cc @kostajh.

@RoySmith could you check what the value of the User-Agent header is in the request? Just want to be doubly sure that incorrect CPU is because your browser is sending that data (instead of CheckUser incorrectly storing the data).

~~Unfortunately, this could be related to user agent reduction and deprecation efforts across various browsers.~~

...and @Dreamy_Jazz already responded with this answer.

When you say "could you check what the value of the User-Agent header is in the request?" I assume you're talking about when I login again? I'll try to grab that the next time this happens.

And, yeah, I have no problem with making the user agent data public. Mac pride!

Ugh. Yeah, I just manually logged out and when I logged back in again the arm Mini is sending:

user-agent:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36

Sorry to have troubled you.

In T374763#10149644, @sbassett wrote:

~~Unfortunately, this could be related to user agent reduction and deprecation efforts across various browsers.~~

...and @Dreamy_Jazz already responded with this answer.

+1. Shall we close this task?

In T374763#10150630, @kostajh wrote:

+1. Shall we close this task?

Yes.

sbassett triaged this task as Low priority.Sep 16 2024, 7:20 PM

sbassett changed Author Affiliation from N/A to Wikimedia Communities.

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".

sbassett changed the edit policy from "Custom Policy" to "All Users".

sbassett changed Risk Rating from N/A to Low.

Before we make this go away completely, is there something that can be done to prevent this? I get that the browser is sending a false UA string, but how is it that we are able to deal with that on other actions and display the client hints instead of the false UA? Why can't we do that in this case?

In T374763#10150988, @RoySmith wrote:

Before we make this go away completely, is there something that can be done to prevent this? I get that the browser is sending a false UA string, but how is it that we are able to deal with that on other actions and display the client hints instead of the false UA? Why can't we do that in this case?

That is tracked in T345818: Store client hint mapping rows for login events; we need to find time to do it. I'm optimistic we could find time for it in the next few months.

Sounds good, thanks.

checkuser reports wrong device for login eventsClosed, InvalidPublicSecurityActions

Description

Details

Related Objects

Event Timeline

checkuser reports wrong device for login events
Closed, InvalidPublicSecurity
Actions