About fdo#47044 crashed when accessing Proxy etc

[Stephan Bergmann]

On 05/30/2012 11:45 PM, julien2412 wrote:
> Quite recently, an interesting bt has been published by "bfoman" about this
> bug (see https://bugs.freedesktop.org/attachment.cgi?id=62055) , here are
> the top lines :
> sal3!rtl_uString_newFromAscii+0x15
> wininetbe1_uno!rtl::OUString::createFromAscii+0x40
> wininetbe1_uno!WinInetBackend::WinInetBackend+0x1a0
>
> Searching about "createFromAscii" in "wininetbackend" files, I found them in
> "wininetbackend.cxx"
> The only lines containing "createFromAscii" are :
>    157             rtl::OUString aProxyList       =
> rtl::OUString::createFromAscii( lpi->lpszProxy );
>    158             rtl::OUString aProxyBypassList =
> rtl::OUString::createFromAscii( lpi->lpszProxyBypass );
>
> Then I wonder what was "lpi" type and just read some lines above :
> 126             LPINTERNET_PROXY_INFO lpi = NULL;
>
> Then searching about LPINTERNET_PROXY_INFO gave this url :
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa385148%28v=vs.85%29.aspx
> "
> typedef struct {
>    DWORD   dwAccessType;
>    LPCTSTR lpszProxy;
>    LPCTSTR lpszProxyBypass;
> } INTERNET_PROXY_INFO, * LPINTERNET_PROXY_INFO;
> "
> So kept on with attributes "lpszProxy" and "lpszProxyBypass" and its type
> LPCTSTR, it gave this link :
> http://msdn.microsoft.com/en-us/library/aa383751%28v=vs.85%29.aspx
> "
> This type is declared in WinNT.h as follows:
>
> #ifdef UNICODE
>   typedef LPCWSTR LPCTSTR;
> #else
>   typedef LPCSTR LPCTSTR;
> #endif
> "
>
> On the same page, we can read :
> for LPCSTR :
> "
> A pointer to a constant null-terminated string of 8-bit Windows (ANSI)
> characters. For more information, see Character Sets Used By Fonts.
>
> This type is declared in WinNT.h as follows:
>
> typedef __nullterminated CONST CHAR *LPCSTR;
> "
>
> and for LPCWSTR :
> "
> A pointer to a constant null-terminated string of 16-bit Unicode characters.
> For more information, see Character Sets Used By Fonts.
>
> This type is declared in WinNT.h as follows:
>
> typedef CONST WCHAR *LPCWSTR;
> "
>
> Then going back to createFromAscii to see if it could match with all this :
> sal/inc/rtl/ustring.hxx    :     static OUString createFromAscii( const
> sal_Char * value ) SAL_THROW(())
> +
> sal/inc/sal/types.h      :     typedef char  sal_Char;
>
> Now I wonder if it's ok to use createFromAscii to manage the attributes
> "lpszProxy" and "lpszProxyBypass" ? (no ironical question here, just a
> beginner question only :-))

wininetbackend.cxx explicitly calls the InternetQueryOptionA variant, so 
the returned lpszProxy and lpszProxyBypass are char-sized strings, so 
calling createFromAscii shall work.  (Strictly speaking, it would cause 
confusion if the strings contained characters outside ASCII, but it 
would not lead to a crash within createFromAscii.)  (And the version of 
LPINTERNET_PROXY_INFO seen in wininetbackend.cxx also is the one using 
LPCSTR, not LPCWSTR, as the call to createFromAscii would otherwise fail 
to compile; and again, char/wchar_t mismatch would not explain a crash 
within createFromAscii, anyway.)

The crash within createFromAscii is near the start of 
rtl_uString_newFromAscii, from the crash information it looks like it 
appears at dereferencing the first byte of pCharStr (aka pTempStr), 
where pCharStr == 0x8fda7dbb.  So it looks like InternetQueryOptionA 
returns with the lpszProxy and/or lpszProxyBypass pointers pointing to 
non-allocated memory.

What one notices is that neither of the two calls to 
InternetQueryOptionA in WinInetBackend check the return value (the first 
shall return with FALSE and GetLastError()==ERROR_INSUFFICIENT_BUFFER, 
while the second shall return with TRUE).  Maybe the call just fails and 
returns FALSE? 
(<http://msdn.microsoft.com/en-us/library/windows/desktop/aa385328%28v=vs.85%29.aspx> 
"Option Flags" in the description of INTERNET_OPTION_PROXY states that 
it is deprecated in favour of INTERNET_OPTION_PER_CONNECTION_OPTION.)

Stephan