Re: MS09-035 Zero Day bug - C / C++ / MFC Discussion Boards

I get it,too.But when i process wm_syscommand in winproc , it run away,hope help.

if(message==WM_SYSCOMMAND)
{
return 0;
}
return ViewItem::WindowProc(message, wParam, lParam);

hi,
i got 1 propertysheet which contain 3 propertypage. I want to make it when program start,it will auto visually click on the radio button for the 1st page.
I had set the OnRadioDirection1() function in my dialog OnInitDialog() and also onSetActive() .But still cannot work.Am i miss up something?

modified on Thursday, September 17, 2009 9:43 PM

If you have one int member variable for the radio button group, set it's value in the page's OnInitDialog() method. Otherwise, if you have a CButton object for each radio button in the group, call the SetCheck(BST_CHECKED) method.

"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

yes. i had set it into
<pre>
static_cast<cbutton*>(GetDlgItem(IDC_TEST))->SetCheck(BST_CHECKED);
OnClick(IDC_TEST);

but still nothing happen. i also had set it for onSetActive().

But when the user "click" to radio button. It will perform well.

first, declare as CButton type member variable in your .h file.
ex : CButton m_RadioBtn1;

after that, in InitDialog, call SetCheck() function and pass TRUE or 1
as argument.

m_RadioBtn1.SetCheck(1);

it should work.

Regards,
Srinivas

and one line is missing,

you should declare in DoDataExchange(CDataExchange* pDX) like :

void CFirstPage::DoDataExchange(CDataExchange* pDX)
{

	CPropertyPage::DoDataExchange(pDX);
	DDX_Control(pDX, IDC_RADIO_AUTOMODE, m_RadioBtn1);
        ......
        ......
}

thats it

Regards,
Srinivas

http://www.microsoft.com/technet/security/bulletin/MS09-035.mspx[^]

We are struggling with how we advise our customers about this issue as we have active-x components in our product.

Here’s a Washington Post article giving some back ground from an independent source:

http://voices.washingtonpost.com/securityfix/2009/07/microsofts_emergency_patch_mes.html?wprss=securityfix[^]

The corrective solution is apply the emergency security patches that Microsoft release for Visual Studio and recompile/re-distribute code to our customers. This also involves installation of new runtime support for Visual Studio code.

It looks like none of the components we produced are vulnerable, however one component in a third party library that we use looks like it might be. We have source to the third party library and can recompile it.

These components are not typically used with a browser so we think it would take some form social engineering attack to use them as a attack vector. But given an exploitable flaw we are holding up a release to get this update into it.

Questions?

1. Do you think the C++ runtimes are vulnerable. I.E. All old applications should be updated so the old C++ run time redistributables can be removed from the environment?

2. How big of an emergency notice should we send out to our customers? Is this potentially a mini Y2K?

3. Does this problem potentionally affect customers of code developed with Visual Studio 97?

Hi Fred,

I can give you some feedback but you should not consider this as security advice.

fredsparkle wrote:
1. Do you think the C++ runtimes are vulnerable. I.E. All old applications should be updated so the old C++ run time redistributables can be removed from the environment?

No, my understanding is that MS09-035 only effects components built with ATL. You can use this graph to determine if your component is effected.

Active Template Library Security Update for Developers[^]

fredsparkle wrote:
2. How big of an emergency notice should we send out to our customers? Is this potentially a mini Y2K?

If your customers are using your ActiveX components in an internet browser and/or your components are marked as safe for scripting then I would consider this a critical situation.

fredsparkle wrote:
3. Does this problem potentionally affect customers of code developed with Visual Studio 97?

My understanding is that this flaw was introduced in Visual Studio 2003 SP1. The flaw exists in the ATL source code distributed with this update. I do not believe Visual Studio 97 is effected.

More information:
Security Bulletin Webcast Q&A - OOB July 2009[^]

I would recommend calling Microsoft customer support services at 1-866-PCSAFETY. Microsoft does not charge for security related issues.

Best Wishes,
-David Delaune

Like many well publicized vulnerabilities, this one is actually rather narrow in the risk. Your application may not even be affected. The following blog clarifies this a little:

http://blogs.msdn.com/sdl/archive/2009/07/28/atl-ms09-035-and-the-sdl.aspx[^]

This isn't remotely close to a mini Y2K (which was also overhyped) and anyone keeping their systems up-to-date have little to fear. Those who don't have FAR worse vulnerabilities to worry about.

I was playing around with a small piece of code that queries port 37 on host 129.6.15.28 to get the date and time. It consistently gives me back 3435973836. Doing the conversion, that's roughly 108.8 years after January 1, 1900 (the epoch). For today, I would have expected a number close to 3461794781. Questions: 1) why would I keep getting the same number, and 2) why is it not the right number?

// error checking has been omitted for brevity
SOCKET rSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
  
unsigned long ul = 1;
ioctlsocket(rSocket, FIONBIO, &ul);
  
SOCKADDR_IN rSocketAddr;
rSocketAddr.sin_family      = AF_INET;
rSocketAddr.sin_addr.s_addr = inet_addr("129.6.15.28");
rSocketAddr.sin_port        = htons(37);
  
connect(rSocket, (LPSOCKADDR) &rSocketAddr, sizeof(rSocketAddr));
  
unsigned int nData = 0;
recv(rSocket, (char *) &nData, sizeof(nData), 0); // returns 4 bytes read
TRACE("%u\n", nData);

Update: initializing nData to 0 answers the questions as to why recv() was consistently assigning 3435973836 to nData. After a few more rounds of testing, the culprit looks to be the call to ioctlsocket() which made the socket non-blocking.

"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

Uhm....Have you seen the hex representation of the number 3435973836 (0xCCCCCCCC)?

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

Yes. I realize it's likely a special value, but without knowing what, it's currently just another number.

"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

I suppose the address of operator will remove the special value.

recv(rSocket, &nData, sizeof(nData), 0);

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

My bad. What I had would have actually resulted in a compiler error (which I obviously don't have).

"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

Hey David, if my understanding is correct, you keep receiving 0xCCCCCCCC. If it is so, you probably are plainly receiving nothing and should check recv return value.
Smile | :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

I am checking the return value, I just didn't bother putting in my code snippet. It's always 4.

"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

Should

recv(rSocket, nData, sizeof(nData), 0);

be

recv(rSocket, (void*)&nData, sizeof(nData), 0);

You need to give recv a pointer to put the data into...

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

PS - you also need to convert the received data (nData) to host byte-ordering from network byte-ordering using ntohl:

unsigned int nData;
recv(rSocket, &nData, sizeof(nData), 0);
nData = ntohl(nData);

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

No matter how you swap 0xcccccccc, it always comes out the same. Wink | ;)

"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

Not if you do it really fast! Smile | :)

But if you implement the other fix I mentioned, you won't be getting 0xcccccccc…I didn't, anyway.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

I was already using a pointer. Had I not been, the code would not have even compiled.

"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

Well I knew only DavidCrow could solve your problem. Big Grin | :-D

BTW eventually I did some test (at home, since I could not reach the server at work), using:

  unsigned long ul = 1;
  unsigned long ul = 0;
  ioctlsocket(rSocket, FIONBIO, &ul);

unsigned long ul = 1;
ioctlsocket(rSocket, FIONBIO, &amp;ul);

```
// without ioctlsocket call
```

For all cases I got reasonable values (growing numbers, starting from 3462291165). What do you think about?
Smile | :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

modified on Friday, September 18, 2009 4:31 PM

What is the difference between 1 and 2? I simply tried with and without the call to ioctlsocket(). The former failed (i.e., recv() never updated the buffer) while the latter succeeded.

"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

DavidCrow wrote:
What is the difference between 1 and 2?

My bad, I fixed it. Blush | :O

What puzzles me is:

Why on my system it works in all cases?
Why on your system, whenever it fails, you get 4 as result of recv?

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]