Security threat due to insecure function "memcpy()" in GCDAsyncSocket.m

This is nearly same question as your other post.

Have you read that there are safe and unsafe ways to call those functions ?

To make it safe against buffer overflow, you need to check that the buffer is large enough to contain all daa you copy.

Did you do that ?

Please provide solution for this as soon as possible as it is very urgent.

Whom is this question to ?
If it is Apple, you should contact developers' support and maybe burn a DTS ticket.

There are multiple ways to slice this. IMO the most productive one is to look at your dependency on GCDAsyncSocket as a whole. Why are you using this third-party code? What does it bring to the party?

My experience with GCDAsyncSocket is that it was never a good idea. Even back when it was written there were better options (like CFSocketStream). Nowadays there is a much better option, Network framework. If you replace GCDAsyncSocket with NWConnection, all of this low-level C code goes away and so do these warnings.

---

If you decide to stick with GCDAsyncSocket then you really need to talk to your management about what will make them happy as far as these warnings are concerned. While these routines are risky, that are a part of standard C and there are circumstances where using them in the right thing to do. If your management decides that you must not use them, it’s up to them to specify what you should be using.

---

Finally, if you decide to make changes to this code, you should consider coordinating with the author of GCDAsyncSocket to see if they are willing to make them upstream.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

Hi Quinn,

you really need to talk to your management about what will make them happy as far as these warnings are concerned.

I am seeing a lot of these warnings due to sprintf(), and the problem I have is that the large number of them clog up the "issue navigator" (or whatever it's called). It's easy to overlook other warnings. So what will make "my management" happy would be disabling the warnings, without also losing other deprecation warnings.

Can you suggest how to disable these specific warnings? I note that, for example, there is/was a preprocessor macro that could be used to hide OpenGL deprecation warnings. Anything like that for these?

Edit: I've just noticed this thread is old. Not sure why it has just popped up. Maybe someone added a post and then deleted it? Hmm.

I've just noticed this thread is old.

Yep. Someone pinged me about the issue privately, which caused me to edit it to fix some stuff.

I am seeing a lot of these warnings due to sprintf

Well, sprintf is deeply insecure and the replacement, snprintf, is usually very easy to adopt, so my inclination is to fix the code.

Can you suggest how to disable these specific warnings?

It is generated by __deprecated_msg and there’s precedent for #defineing that away.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Security threat due to insecure function "malloc()" in CDVAssetLibraryFilesystem.m, CDVDevice.m and srp.h