New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 728635 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Long OOO (go/where-is-mgiuca)
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: ----
Type: Bug-Security
Team-Security-UX



Sign in to add a comment

Security: Chrome Mobile Browser Address Bar spoofing via RTL with IP

Reported by athuljay...@gmail.com, Jun 1 2017

Issue description


VULNERABILITY DETAILS

1. User Input in chrome mobile browser address bar

<ip-address or digits of n length>/<any arabic string or arabic+chinese string of n length>/<any EN string or domain name>

OR
<any arabic string or arabic+chinese string of n length>/<any EN string or domain name>

(Here n be a integer of any value)


2. Attack vectors:

43.22.11.33/تمامی مطالب مربوط به روتر های/mozilla.org

54.43.112.124/ مطالب مربوط به روتر های  你好,你好吗/mozilla.org




3. Results:

Browser started fetching HTTP GET with the reverse of the input string i.e Last Portion of the string placed in the beginning of the string.



43.22.11.33/تمامی مطالب مربوط به روتر های/mozilla.org  to

mozilla.org/<arabic language>/43.22.11.33



54.43.112.124/ مطالب مربوط به روتر های  你好,你好吗/mozilla.org  to
你好,你好吗/54.43.112.124/<arabic language>/mozilla.org




4. Proof of concept
https://youtu.be/ciyHyWkukqU

 





VERSION
Chrome Version: 58.0.3029.83 Stable
Operating System: Android 6.0.1; SM-J500F Build / MMB29M




 
Components: UI>Browser>Omnibox UI>Security>UrlFormatting
This looks like Issue 638818.
Summary: Security: Chrome Mobile Browser Address Bar spoofing via RTL with IP (was: Security: Chrome Mobile Browser Address Bar)
Owner: mgiuca@chromium.org
Status: Assigned (was: Unconfirmed)
This looks like a dup of 351639 to me, but assigning to mgiuca to confirm.
Cc: jdonnelly@chromium.org
Labels: -Restrict-View-SecurityTeam OS-Android
Status: WontFix (was: Assigned)
(No it isn't either of those.)

This is the same  Issue 495933  which was fixed a long time ago. The string:

43.22.11.33/<arabic-text>/mozilla.org

When rendered as a URL needs to be rendered as a LTR paragraph, and hence should render in logical order:

43.22.11.33/<arabic-text>/mozilla.org

However, when rendered as plain text (not a URL), its paragraph direction is "auto" meaning it takes the first strong character, which is an Arabic character in this case. That means it's rendered as an RTL paragraph:

mozilla.org/<arabic-text>/43.22.11.33 (and right-aligned).

On Android, the Omnibox renders as plain text when editing, and as a URL when not editing. The video only shows this bug when the user has the text field selected for editing. That is working as intended.

There is no security risk because when the user is viewing the page, the URL bar correctly shows the host on the left.

Sign in to add a comment