Community
Participate
Working Groups
Build ID: I20090611-1540 Steps To Reproduce: 1.Open the attached file 2.Choose either Text Editor/Aptana HTML Editor/Subclipse compare/ tbc 3.Cross-check the file with a hex editor/open with a browser More information: Null-bytes seem to hide the information positioned behind them. This can be used for smuggling arbitrary code which is not likely to be found during daily work flow.
Created attachment 141363 [details] test case html w. nullbytes and trailing XSS vector
It seems to work only on *nix based systems so far. Tested were Ubuntu 9.04 32Bit (success) and the same Eclipse revision on Win XPSP2 32 (fail). Not tested yet were Mac OSX and other operating systems. The hidden code in the test-file resists editing/saving, SVN commits, exports and other comparable interaction/modification. A copying of the file doesn't impact the content - so the overhead is being noticeable via file size. Copy-pasting the text itself is OS dependent regarding result. Please see the attachment for a demonstration. Excuse the lack of choice in the drop-down for 'Component' - I had no idea what to select..
Created attachment 141364 [details] demo screenshot
Just in case someone is interested - I justed tested this on an Eclipse running on latest Kubuntu (9.0.4) with KDE 4.2.2 .- exact same result.
Could be an SWT or Text problem.
Praveen, do you want to take a look at this?
Sure, I will take a look.
Upon investigation, it appears that this to be the JRE IO-classes problem on Linux. The function ResourceTextFileBuffer.setDocumentContent() is responsible for reading the contents of the (resource) file through BufferedReader. However, when the file contains a 'null' byte, then the characters following the null byte are not filled into the buffer. Though the API Reader.read(char[]) returns the correct number of bytes, the array is not filled with the characters position beyond the null character. However, on Windows, the API fills the characters in the right manner. Since the problem happens due to JRE of Linux itself, I have a reported a bug against Sun JRE (Review ID: 1635046). As the rootcause of the problem is in org.eclipse.core.filebuffers, should this be routed to platform-text-inbox ?
Which SDK version? Did you verify whether it's fixed in a newer version?
(In reply to comment #9) > Which SDK version? Did you verify whether it's fixed in a newer version? I tried against Java 1.4 and 1.6 (on my machine), and the problem appears on both of them.
Did you also try the IBM VMs?
I can confirm that something similar is also happening on Ubuntu 10.04 with an IBM 1.5 VM. One difference is that I can still see the characters after the null bytes. Also, When I move the cursor with the left and right arrow keys it seems as though the cursor moves over these null bytes even though it doesn't move anywhere. I move x characters to the right (using the right arrow key) I have to type the left arrow key x+1 times before the cursor moves left of where it was before (one character before the last non-null byte). I would expect that if the bytes are not shown then the cursor should behave consistently. vi shows the characters as "^@" and open office just shows them just as "#".
This version of Ubuntu is no longer a supported target environment, please file a new ticket against 4.9/4.10 if the issue occurs on Ubuntu 18.04.
