Larry Osterman

I just received this phishing letter, I liked it simply because it was so remarkably brazen:

--

Dear Webmail User,

This message was sent automatically by a program on Webmail which periodically checks the size of inbox, where new messages are received. The program is run weekly to ensure no one's inbox grows too large. If your inbox becomes too large, you will be unable to receive new email.

Just before this message was sent, you had 18 Megabytes (MB) or more of messages stored in your inbox on Webmail. To help us re-set your SPACE on our database prior to maintain our INBOX, you must reply

to this e-mail and enter your Current UserID: ( ) and

Password ( ) Select server ( ) if any

You will continue to receive this warning message periodically if your

inbox size continues to be between 18 and 20 MB. If your inbox size grows

to 20 MB, then a program on Webmail will move your oldest

email to a folder in your home directory to ensure that you will

continue to be able to receive incoming email. You will be notified by email

that this has taken place. If your inbox grows to 25 MB, you will be unable to

receive new email as it will be returned to the sender.After you read a

message, it is best to REPLY and SAVE it to another folder.

Thank you for your cooperation.

Webmail Help Desk

---------------------------------------------------------------------------

3webXS HiSpeed Dial-up...surf up to 5x faster than regular dial-up alone...

just $14.90/mo...visit www.get3web.com for details

 

The email was in plain text from “Webmail Service Support [general@3web.net]” (I don’t feel bad about including their real email address on a post on the web, after all they deserve to get spam, right?

 

As I said, I thought it was remarkably brazen and very low budget.  Why bother trying to set up a domain when you can get the victim to send you their credentials by email :).

Yesterday I described a very real bug in some of the Windows UI.

CControlLayout::CControlLayout(const HWND hWndControl, const HWND hWndDlg) : m_hWnd(hWndControl) , m_hWndDlg(hWndDlg) { // Get the parent (dialog) rect, and the control rect ::GetClientRect(m_hWndDlg, &m_rcRefDlg); ::GetWindowRect(m_hWnd, &m_rcRef); ScreenToClientRect(hWndDlg, m_rcRef); } void ScreenToClientRect(/* [in] */ const HWND hWndClient, /* [in/out] */ RECT &rcInOut) { CPoint ptTopLeft(rcInOut.left, rcInOut.top); CPoint ptBottomRight(rcInOut.right, rcInOut.bottom); ::ScreenToClient(hWndClient, &ptTopLeft); ::ScreenToClient(hWndClient, &ptBottomRight); rcInOut.left = ptTopLeft.x; rcInOut.top = ptTopLeft.y; rcInOut.right = ptBottomRight.x; rcInOut.bottom = ptBottomRight.y; } .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }

And as David Gladfelter pointed out, the root cause of the problem is that the routine calls ScreenToClient.  This works just fine when you’re running on Left-to-Right builds of Windows, but on Right-to-Left languages (Arabic, Hebrew, etc), this code sets the rcInOut.left to the wrong location.

It turns out that MSDN has a warning that is explicitly about this kind of problem:

For example, applications often use code similar to the following to position a control in a window:

Copy Code

// DO NOT USE THIS IF APPLICATION MIRRORS THE WINDOW // get coordinates of the window in screen coordinates GetWindowRect(hControl, (LPRECT) &rControlRect); // map screen coordinates to client coordinates in dialog ScreenToClient(hDialog, (LPPOINT) &rControlRect.left); ScreenToClient(hDialog, (LPPOINT) &rControlRect.right);

This causes problems in mirroring because the left edge of the rectangle becomes the right edge in a mirrored window, and vice versa. To avoid this problem, replace the ScreenToClient calls with a call to MapWindowPoints as follows:

Copy Code

// USE THIS FOR MIRRORING GetWindowRect(hControl, (LPRECT) &rControlRect); MapWindowPoints(NULL, hDialog, (LPPOINT) &rControlRect, 2)

It turns out that this is explicitly the mistake that was made in the code.  The good news is that the “Use this for mirroring” code listed in the article is exactly the fix necessary to solve this problem.

 

As I mentioned, David Gladfelter was the first person to pick up the problem, kudos to him!

Wow, 25 already.

This one’s pretty straightforward.  Once again, it’s a UI issue, since I’ve been spending most of my time doing UI lately.

In this particular case, the code comes from the constructor for an auto-layout class that is used internally in one of our tools.  It saves away window handles for a control and the dialog which holds the control, then saves the size of the dialog and relative location of the control within that dialog.  There’s other code that handles resizing and adjusting the layout of the control when the dialog is resized. 

CControlLayout::CControlLayout(const HWND hWndControl, const HWND hWndDlg) : m_hWnd(hWndControl) , m_hWndDlg(hWndDlg) { // Get the parent (dialog) rect, and the control rect ::GetClientRect(m_hWndDlg, &m_rcRefDlg); ::GetWindowRect(m_hWnd, &m_rcRef); ScreenToClientRect(hWndDlg, m_rcRef); }void ScreenToClientRect(/* [in] */ const HWND hWndClient,
                        /* [in/out] */ RECT &rcInOut)
{
 CPoint ptTopLeft(rcInOut.left, rcInOut.top);
 CPoint ptBottomRight(rcInOut.right, rcInOut.bottom); ::ScreenToClient(hWndClient, &ptTopLeft);
 ::ScreenToClient(hWndClient, &ptBottomRight); rcInOut.left = ptTopLeft.x;
 rcInOut.top = ptTopLeft.y;
 rcInOut.right = ptBottomRight.x;
 rcInOut.bottom = ptBottomRight.y;
}
.csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }

m_rcRefDlg holds the reference rect for the dialog and m_rcRef holds the reference rect for the control relative to the dialog.

This code has been in the UI for quite a while and recently one of our testers discovered a nasty bug while running a test pass.

The question is: What’s wrong with this code.  I believe we shipped Windows Vista with this bug (I’m not 100% sure, since I don’t have a Windows Vista machine to test it), so it’s pretty subtle.

 

Edit: OOPS - I forgot to include ScreenToClientRect.