Luke1410
commented
7 years ago I think you misunderstood the statement. Maybe it was also not too well phrased, to begin with (allowing such misinterpretation to occur). In this case, I'm happy for any suggestions to improve the wording.
I assume you are referring to the following statement in section 1.3 ("Changes between RakNet (4.081/4.082) and SLikeNet") of the readme file: "[...] The major differences/improvements of SLikeNet over RakNet are: [...]
- security enhancements (f.e. by fixing buffer overflows, using security enhanced CRT functions, replacing obsolete less secure CRT functions with up-to-date ones, etc.)
[...]"
First of all I've to make it clear that software security is something which we do understand is tackled and ensured by not only a single golden bullet but rather by a collection of different processes and establishing high quality standards. While we are striving towards the goal to make SLikeNet a network library which provides a top level of security, we certainly aren't there yet. This is, first of all, reflected by the fact that SLikeNet in its current version is still a development version and hasn't even reached alpha-quality-level (by our own standards) yet. Still, building upon RakNet, we honestly think that even in its current early state it's an improvement over the quality standards of RakNet.
That said, the purpose of the list in the readme file is solely meant to give examples of where SLikeNet improves things over those which are available in RakNet. No more, no less.
With regards to security, we made already some initial steps to raise the security standard of the library. The list provided here doesn't reflect all the changes done, but rather gives some examples. a) several buffer overflows in RakNet were fixed (some of which were discovered during code review and with the use of static code analysis tools; others were fixed based on pull requests and issue reports on GitHub or reported by customers) b) we decided to use the security-enhanced versions of CRT functions (see [1][2][3]) simply because they provide an additional layer of protection against common coding bugs which can lead to security relevant issues (like buffer overflows). For instance the strcpy() function does not validate whether the given destination buffer is large enough to retrieve the string copy whereas strcpy_s() takes the size of the destination buffer and therefore can check that no buffer overflow occurs (under the premission that the passed parameters are correct of course). This doesn't only have the advantage of these additional compile and runtime checks for us, but also allows easier code reviews (be it manual or automated ones) since you directly see the destination buffer size. We certainly understand that the use of these security-enhanced CRT functions can be seen controversial and there's no doubt that there are also arguments against using these. Feel free to make your point why you would advice against using these in SLikeNet, but atm we think that the advantages outweight the disadvantages (take into consideration also that several of these functions made it into the C11 standard and the old argument using these violating standard compliance no longer stands for all cases which were risen when Microsoft introduced these back in VS 2005). c) completely independent of the security-enhanced versions of CRT functions mentioned above, RakNet used some deprecated functions. One example being gethostbyname() [4]. These deprecated functions were replaced with their newer counterparts (f.e. in case of gethostbyname() we use getaddrinfo() now). Some of these deprecated functions had security related flaws. Therefore, we listed this here (f.e. gethostbyname() doesn't check the size of the name parameter and hence could trigger a heap corruption if improperly used). As said: This entry in the list of changes is completely unrelated to the previous point of the security-enhanced versions of CRT functions.
As stated above: These are just some examples of how we improved the security of RakNet in SLikeNet. There are other things we did which aren't explicitly mentioned in the readme and some of which are also done outside the code (f.e. using static code analysis, certain procedures we do as part of the release procedure, additional testruns, etc.). Also note that we just got started here, and you'll see more changes to follow which further increase the security level of SLikeNet in the upcoming versions. For example for 0.2.0 we will process more of remaining/outstanding pullrequest/issue reports and also will raise certain dependencies to resolve other known (and unknown) (security) issues.
I hope this answers your questions and that we'll be able to show you already with the next version that indeed we take the security concerns on the library seariously. If you have concrete issues you'd like us to tackle here, don't hesitate to state them. Also if I got your question wrong, don't hesitate to ask again.
[1] https://docs.microsoft.com/en-us/cpp/c-runtime-library/security-features-in-the-crt [2] https://docs.microsoft.com/en-us/cpp/c-runtime-library/security-enhanced-versions-of-crt-functions [3] http://resources.infosecinstitute.com/sdl-for-cc-code-in-visual-studio-2013-overview/#gref [4] https://msdn.microsoft.com/en-us/library/windows/desktop/ms738524(v=vs.85).aspx
pps83
Kiddinglife
After reading these statements I would not trust your changes more than original raknet which scores solid 0 on 0 to 10 scale. I strongly suggest you to fix these bugs: there is no "enhanced" CRT function. There are standard C functions and raknet used to use them. "obsolete less secure CRT functions" - who and since when obsoleted standard functions?!