C / C++ / MFC Discussion Boards

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]

CPallini wrote:
Why on my system it works in all cases?

Other than error checking, do you have any more/less code than what I've shown?

"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

Hello

Can anyone tell me how to convert Julian date/time to Normal (standard) date/time
and back?

Any sample source code will help?

I do have some code, but the problem is, if the TIME is before 12 Noon, then it will
show the previous DAY.

i.e., if the actual time now is Sep 17th 10:30 AM

My code will give me the date as Sep 16th 10:30 AM

But if the current time is Sep 17th 10>30 PM

then it will give the exact day.

dipuks wrote:
Can anyone tell me how to convert Julian date/time to Normal (standard) date/time
and back?

What is your Julian date's epoch?

Have you seen this?

What does your date/time value look like?

"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

what is a epoch?

am very new to julian date/time

dipuks wrote:
what is a epoch?

See here.

"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

starting from 1 january 1899 to current date

Ok the problem that i am having is with calculating the time...

i.e, if the time is BEFORE NOON, that is an hour value less than 12,
then the calculation gives a negative number.

when that is added with the DAY number, it actually goes back by a day.

It seems there's no perfect way of calculating the julian time if hour is less than 12?