Soldier
Regular
- Joined
- 20.10.20
- Messages
- 88
- Reaction score
- 737
- Points
- 83
Independent information security expert Pedro Oliveira spoke about the bug CVE-2020-15647, which he discovered in the spring of this year in Firefox for Android. A specially created HTML file could be used to steal cookies from the victim's device.
The vulnerability was how Firefox handles local files via the content:/ / URI. Exploiting the bug allowed you to remotely get copies of cookies from the device, which gave the attacker access to some sites viewed by the user.
To exploit the problem, you had to convince the user to open a specific HTML file. The malicious file opened an iframe that called the content:/ / URI for profiles. ini, which contains data about the Firefox user profile, as well as cookies. Because the URI processing in Firefox was not performed correctly, the researcher was able to get a copy of this local file, which should not be accessed via the web page.
The researcher explains that the browser redirects the content: / / URI to access local files on the device to the file://URI, making it clear that before downloading, it saved a copy of the requested resource to a directory with a private cache.
"These content: / / URIs require read and write permissions so that they can be accessed by other applications. When you share a URI between applications (for example, via Share with), the source application must grant permissions for this URI (before sharing). As a result, the URI has permissions when it is shared with the recipient application, and only it can access it. However, when the application itself processes its own URIs (and not other applications), these permissions are not applied, meaning the application can freely access the content, " says Oliveira, noting that any file downloaded by Firefox before version 68.10.1 was handled this way.
So as a malicious file, which was discussed above, and the local file that is loaded by the exploit, have the same names in the private directory there is a substitution. As a result, the expert explains, the attacker gets an open malicious cached file, and the source file is replaced. After loading the iframe, the cached malicious file sends its content to the malicious page, where the attacker sees it. Since the path and source have not changed, no warnings are displayed.
This vulnerability was fixed in the summer of this year, when Firefox was updated to version 68.10.1.
The vulnerability was how Firefox handles local files via the content:/ / URI. Exploiting the bug allowed you to remotely get copies of cookies from the device, which gave the attacker access to some sites viewed by the user.
To exploit the problem, you had to convince the user to open a specific HTML file. The malicious file opened an iframe that called the content:/ / URI for profiles. ini, which contains data about the Firefox user profile, as well as cookies. Because the URI processing in Firefox was not performed correctly, the researcher was able to get a copy of this local file, which should not be accessed via the web page.
The researcher explains that the browser redirects the content: / / URI to access local files on the device to the file://URI, making it clear that before downloading, it saved a copy of the requested resource to a directory with a private cache.
"These content: / / URIs require read and write permissions so that they can be accessed by other applications. When you share a URI between applications (for example, via Share with), the source application must grant permissions for this URI (before sharing). As a result, the URI has permissions when it is shared with the recipient application, and only it can access it. However, when the application itself processes its own URIs (and not other applications), these permissions are not applied, meaning the application can freely access the content, " says Oliveira, noting that any file downloaded by Firefox before version 68.10.1 was handled this way.
So as a malicious file, which was discussed above, and the local file that is loaded by the exploit, have the same names in the private directory there is a substitution. As a result, the expert explains, the attacker gets an open malicious cached file, and the source file is replaced. After loading the iframe, the cached malicious file sends its content to the malicious page, where the attacker sees it. Since the path and source have not changed, no warnings are displayed.
This vulnerability was fixed in the summer of this year, when Firefox was updated to version 68.10.1.