alexti2 said:
It is probably pointless to post anything constructive here, but I'll try anyway.
We'll see.
Using library that has known vulnerability does not necessary make your product vulnerable.
At the very least it makes you irresponsible and incompetent, especially when a new fixed library is easily available.
What happens when you install such an outdated insecure library in a common file access folder/path?
Even assuming your clever application duplicated the libraries code but yet somehow fixed it to prevent your application from being affected, it would still be available for other applications to use.
Granted, Civ 4 doesnt install its third party DLLs in any sort of common folder/path, but since we are talking in general terms, it has to be considered.
Why use a version of a library that has known vulnerabilities, when newer less vulnerable more bug fixed versions are available?
(aside from irresponsible incompetence)
Commonly, vulnerability arises from some memory overrun in some function when it's provided with particular input.
<insert explanation of what an unchecked buffer is, then explain a buffer overrun attack exploit>
There are lots of "common vulnerability" types. Unchecked (or improperly checked) buffers are one type.
But yes, they are "common". One of the two zlib flaws is in fact as such.
Then the application that never calls this function (directly or indirectly) never risks this overrun and doesn't have this particular vulnerability.
Its a good thing no application ever needs to inflate what it deflates. Fantastic point!
I mean, if the flaws were in the inflate() and inflateBack() functions, that would be Really Bad, because of course, deflated data, needs to be inflated, what with that funky "compression" and "decompression" process stuff.
The application may even use this function and as long as it ensures that the set of parameters that would cause memory overrun can't reach that function.
Well, how would it know that? Does the application have mystical knowledge of all the flaws and shortcomings of the third party code library?
Somehow it has a better idea of how to process the data for the library, than the library itself eh?
If thats the case, why use the external third party code library at all? Why not just write "their" own code, since obviously "they" have a much better idea of how to process the data?
Of course, that defeats the purpose of using an external third party code library. And of course, Civ 4 uses an external third party code library - an outdated insecure one.
This can be either due to the progammer being aware of vulnerability and adding safeguard or due to the only limited inputs arising from within the application (not from external sources) being fed to this functions.
So, instead of just getting the updated fixed secured DLL (a few minutes max?), you use the old outdated insecure library, and then spend who knows how long coding extra checking code into your app using detailed knowledge only obtainable through significant research time spent figuring out the nature of the flaws.
Which means you'd have to know about the flaws, the flawed version, but still include it anyway.
Clever.
Well, if this is the case, then i'm sure we'll never see an updated ZLIB1.DLL or PYTHON24.DLL from Firaxis.
If in fact the patch does contain an updated version of either, thats primae facie evidence that in fact, they had no such code, and of course, that they acknowledge Civ 4 to be insecure as shipped.
Of course, i've already heard from one source that the patch contains ZLIB1.DLL version 1.2.3 - the latest secured version.
However, they neglected to update PYTHON24.DLL as well. Utter incompetence.
Its moot now - Civ 4 shipped insecure, and the release of the patch with ZLIB1.DLL implicitly acknowledges this.
Because of these reasons it's impossible to say if Civ4 has any of those vulnerabilities or not without detailed investigation.
Its not impossible - its utterly possible and factual. Civ 4 ships with outdated insecure code libraries. Those two libraries contain utterly insecure vulnerable code. If you want to argue they cant be exploited, thats another argument (see your previous attempt). But the insecure vulnerable code is most definitely there.
It didnt take much investigation by myself to see they were using outdated third party code modules. Or that two of them contain a copy each of the two zlib vulnerabilites (ZLIB1.DLL and PYTHON24.DLL).
Its vulnerable. It shipped with vulnerable libraries, and the first patch specifically contains at least 1 secured library.
It would be nice to get a statement from Firaxis on this issue.
Indeed. You would think it would be a priority for them. Ah, but why issue a statement when you can just release a half-ass patch that only secures one of the vulnerable libraries?
You have to love incompetence. Especially when it puts you and your computing experience at risk.
Having the source code it shouldn't be too hard to find out if their appllication is vulnerable or not.
Its vulnerable. We already know. The patch includes ZLIB1.DLL version 1.2.3.
Still, as long as one doesn't allow Civ4 to access the internet and doesn't load any mods or savegames from untrusted sources, he will be save from exploits.
Perhaps. Though, its probably more reasonable just to update the DLLs as recommended - you get the advantage of the secured libraries, not to mention the other non-security related bug fixes, and the ability to more fully use the game without "worry".
I just wanted to see people STOP bashing CivIndeed 
