Bugzilla

(In reply to Surya Dev Singh from comment #0)
> Created attachment 9445828 [details]
> XSS_Using_Jar_File.png
> 
> Firefox for Android
> 
> Steps to reproduce:
> 
> A vulnerability in the jar: protocol parser of Mozilla Firefox allows filename and extension spoofing and MIME type manipulation leads to XSS when a null byte (%00) is included in the entry name of a JAR archive. This can result in malicious code execution, such as triggering JavaScript payloads embedded in image files by spoofing the file extension and MIME type. 
> 
> [+] Screenshot Attached below , I can only attach one screenshot, if need more details please reach me out!!
> 
> 
> Actual results:
> 
> Create a Malicious File:
> 
> 1) Embed a JavaScript payload in the EXIF data of an image file (e.g., hacker.png) using the Exiftool like so : exiftool -Comment=<script>alert('XSS By Surya Dev Singh')</script>" hacker.png
> 
> 2) Place the image (hacker.png)  file in one folder (lets say hacker) and archive it to zip (jar files are basically zip file only so you can rename the generated zip file to something like hacker.ja) 
> 
> 3) Try to load the  hacker.png file using the normally using the jar protocol :  jar:file:///C:/Users/Username/Desktop/hacker.ja!/hacker/test2/hacker.png
> It will load the image normally.
> 
> 4) But if you modify the URL by injecting Null Byte , it will terminate the "AUTF8String JAREntry" entry definition from the code . the modified URL would look like this : 
> jar:file:///C:/Users/Z004WREN/OneDrive%20-%20Siemens%20Healthineers/Desktop/hacker.ja!/hacker/test2/hacker.png%00.html
> 
> 5) This will Trigger the XSS payload that we have store in Exif comment data.
> 
> 6) Now we can use this Null Byte Behavior with some slide modification to change the file name and its extension . which further means that we can change the mime type of the file . Thus will trigger an user to run the malicious file as non malicious file. 
> 
> 7) to do that we need to to add "://<custom_filename>" after the null byte termination. like so : 
> 
> jar:file:///C:/Users/Z004WREN/OneDrive%20-%20Siemens%20Healthineers/Desktop/hacker.ja!/hacker/test2/hacker.png%00://definitely_not_a_hacker_file.exe
> 
> This will download the hacker.png file as "definitely_not_a_hacker_file.exe" with executable extension.
> 
> -------------------------------------------------------
> 
> 
> All this behavior has been trigger due to the vulnerable code base in mozilla :
> The two classes GetJARFile and GetJAREntry makes heavy use of nsCString (likely a Mozilla-specific wrapper around std::string or a similar container) and other string types. Functions that process strings could be vulnerable if the null byte is mishandled. Here’s a potential scenario:
> 
> In SetSpecWithBase(const nsACString& aSpec, nsIURI* aBaseURL), the code likely constructs and manipulates URLs. If the aSpec string contains a null byte in an unexpected location, the  nsIJARURIMutator function is then not able to handle the input that's coming from the  GetJAREntry . it might cause string manipulation functions (e.g., strlen, strcpy, strcat) to terminate prematurely or lead to buffer overflows/underflows.
> 
> The methods that handle strings (such as SetPathQueryRef, SetHostPort, SetRef) could all be susceptible to this issue if they don't handle strings properly
> 
> 
> Here are link to codebase : 
> 
> https://searchfox.org/mozilla-central/source/__GENERATED__/dist/include/nsIJARURI.h#35
> 
> 
> 
> 
> Expected results:
> 
> what  should have happened : 
> 
> The jar: protocol parser should correctly handle null bytes (\0) in filenames, preventing filename and extension spoofing. 
> 
> The MIME type of the file should remain consistent with its actual content and extension, disallowing manipulations.
> 
> Files within JAR archives should be securely validated and sanitized to prevent execution of embedded scripts.
> 
> No JavaScript payload embedded in non-HTML files should execute, even with manipulated MIME types.

Hello Team !!
 
Thank you for your reply !! Here is the full step by step POC that I have given, and screenshots are also attached for the same . 
any person responsible to triage of the bug can easily use this step to reproduce the bug described. 
This is what standard POC look like. but if you prefer it in some video form I can do it. I understand that screenshots can be faked, but this is what standard triage process goes in checking the validity of the POC I have given. 

This a security bug should be triage and responded immediately to reduce the risk of its exposure so that a CVE id can be assign to it, since I have not reported it on hackerone. The Mozilla team can directly take a look at it here itself or can ask the team that review the bugs from the Hackerone mozilla bug bounty ( if there is a different team) . looking forward into this !! 

Thank You !!

[_trimmed unnecessary quote of comment 0_ -dv]

Hello Team !!
 
Thank you for your reply !! Here is the full step by step POC that I have given, and screenshots are also attached for the same . 
any person responsible to triage of the bug can easily use this step to reproduce the bug described. 
This is what standard POC look like. but if you prefer it in some video form I can do it. I understand that screenshots can be faked, but this is what standard triage process goes in checking the validity of the POC I have given. 

This a security bug should be triage and responded immediately to reduce the risk of its exposure so that a CVE id can be assign to it, since I have not reported it on hackerone. The Mozilla team can directly take a look at it here itself or can ask the team that review the bugs from the Hackerone mozilla bug bounty ( if there is a different team) . looking forward into this !! 

Thank You !!