Marco Tech Blog

August 19, 2014

Fix for Buffer Overflow in VCL Bitmap Processing Code

A potential buffer overflow condition in the VCL bitmap processing code (specifically in the function PaletteFromDIBColorTable) could be potentially used to inject malicious code into an application. The problem goes back to the early days of Delphi (and C++Builder) and a code fix is available for all.

posted by marcocantu @ 3:01PM | 18 Comments [0 Pending]

Fix for Buffer Overflow in VCL Bitmap Processing Code 

There is something wrong. You added 2 lines of code. 
But the hotfix is 72 MB in size!!! ????

Comment by Peter on August 19, 15:27

Fix for Buffer Overflow in VCL Bitmap Processing Code 

 The technique that you recommend to 
apply the fix in older versions does not 
work in XE6. That is, adding the VCL 
source file to the project, modifying 
implementation section, and compiling, no 
longer works. Doing so results in the 
"unit xxx was compiled with a different 
version of unit yyy". This has been 
discussed a few times recently on Stack 
Overflow. Warren Postma asked a question 
on this subject not so long ago. There 
have been others. 

So if you need to apply a fix down the 
line in this way, you'll be stuck. Did 
Emba mean to break this very useful 
technique. Personally I am upset about 
this because I use this technique to fix 
various RTL/VCL bugs that Emba won't fix. 
So I'm very reluctant to move to XE6. 

Comment by David Heffernan on August 19, 18:41

Fix for Buffer Overflow in VCL Bitmap Processing Code 

Peter,

  if you consider debug and release DCUs, dependent DCUs, 
runtime packages, and all of the related files for woth Win32 and 
Win64, things add up rapidly.

David,

  if you change only the implementation portion, there should be 
no need to recompile dependent units. In the opposite case, you 
have to provide a link to the source (like the VCL source) so that 
the compiler can recompile from source all of the dependent units.
In any case I took XE6, copied the file, added it to a project, made 
the suggested change, and it did recompile as expected.

Willing to investigate more about the issue, I think I saw it myself. 
But it doesn't apply in this case, from what I can see.

-Marco

Comment by Marco Cantu [http://www.marcocantu.com] on August 19, 21:16

Fix for Buffer Overflow in VCL Bitmap Processing Code 

Does not IDE have a vulnerability? (XE5 or earlier)
- Property Editor
- *.DFM (Embedded Image)

Comment by Hideaki Tominaga [http://ht-deko.minim.ne.jp/] on August 20, 01:33

Fix for Buffer Overflow in VCL Bitmap Processing Code 

 That's right, change only the 
implementation section. Warren's question 
is here:

    http://stackoverflow.com/q/24145214/

I recall from my investigations that 
other units exhibited the same issue. 
Can't check now as I am not near Delphi. 
I think this is a real problem. 

See also this question which reaches the 
same conclusion for a different unit:

    http://stackoverflow.com/q/24412299/

Comment by David Heffernan on August 20, 05:05

Fix for Buffer Overflow in VCL Bitmap Processing Code 

Thanks Marco. There is on problem: The provided
solution does not work with runtime packages. Any
way/idea how to recompile the VCL runtime packages to
apply this fix? Turning off runtime packages is not a
realistic option (i have a big project with many
runtime packages on XE2). May there is a solution to
"patch" the function at runtime but i guess thats a
hard one because the function is only in the
implementation section of Vcl.Graphics. Any idea?

Comment by Elias Zurschmiede [http://www.delight.ch] on August 20, 07:15

Fix for Buffer Overflow in VCL Bitmap Processing Code 

Hello,

I have XE3

When doing steps what are provided in support article,
I'm receiving multiple compiler warnings of
Unsupported language feature: 'custom attribute' and
one Symbol 'AnsiLowerCaseFileName is depracated: 'Use
AnsiLowerCase instead warning.

So is there better solution for applying this security
fix?
 

Comment by Marko Hietanen on August 20, 15:52

Fix for Buffer Overflow in VCL Bitmap Processing Code 

 @Elias I think a runtime patch wouldn't 
be too hard to arrange in a package. If 
you asked a Stack Overflow Q then I'm 
sure somebody would help. I personally 
cannot do so for the next week but 
somebody else will. One way to do this 
would be to use a class helper to crack 
the private member. And then a simple JMP 
detour does the rest. 

Comment by on August 20, 18:58

Fix for Buffer Overflow in VCL Bitmap Processing Code 

It's good to see this fix.  I'll make sure to get it
installed right away on my own projects.

I have to ask, though. Does anyone know what's gong on
with the Embarcadro forums?  They've been offline for
several days now...

Comment by Mason Wheeler [http://tech.turbu-rpg.com] on August 20, 20:53

Fix for Buffer Overflow in VCL Bitmap Processing Code 

""This is the first security fix for Delphi I 
remember ever seeing. " Which is dearly good, given 
how many security patches most other software 
programs require. Just saying."

I'll be very careful to say this, until a full 
security audit of Delphi code has been performed. 
Delphi still has a lot of code dating back many years 
ago, when security was less important.
And while, for example, VC++ RTL introduced a lot 
of "safe" functions when memory buffers are involved, 
I don't know how much safe Delphi RTL functions are.
Hope OpenSSL debacle taught something... of course 
some applications are under more scrutiny than 
others, because of their diffusion and because they 
could be good attack vectors (browsers, Flash, PDF, 
Java...). And I wish I could not talk of Datasnap 
again - and the same mistakes were repeated in the 
AppRemote library.
And because Embarcadero is not going to patch them 
but for the latest version, I guess it's time users 
are enabled to recompile run-time packages if they 
need so. Otherwise instead of being a good reason to 
move to a new version of Delphi, it becomes a good 
reason not to rely on it for any big, important 
application that can't be upgraded to the latest 
version every 6-8 months or little more.

Comment by on August 21, 21:54

Fix for Buffer Overflow in VCL Bitmap Processing Code 

Regarding recompiling packages this has always been possible. 
What you are not allowed to do is to recreate the same packages, 
with the same name and distribute them, as they might be shared 
by different applications on the same computer. But you can create 
a new package with the  VCL source code units (well, even better, 
pick only those you effectively use) and distribute this new package 
along with your application.

As the security (the anonymous post above), Delphi recently 
embraced some of the secure functions Microsoft suggest (at 
startup we do call some string processing system functions). 
However, only recent versions of Delphi (I think XE4, but not 100% 
sure) have this extra security. A lot of Delphi applications are 
screened for security and we take those results very seriously. As 
you can see, when there is a serious issue even if we don't patch all 
old versions we try to provide timely information to customers. 
However, if security is a concern, I'd recommend using the most 
recent versions of our tools, as you'd use recent operating systems 
and recent, updated applications.

Comment by Marco Cantu [http://www.marcocantu.com] on August 22, 07:57

Fix for Buffer Overflow in VCL Bitmap Processing Code 

Creating new packages with different names won't help 
because third party packages will still target the 
standard ones. From where they will load patched 
units? Should we modify each and every third party 
package, as long as we have source code?
Microsoft is telling developers for many years to put 
DLLs inside application folders to avoid DLL hell, 
and avoid shared DLLs. Usually, the reuse of memory 
which was the main reason to use shared DLLs is very 
little useful today.
If you can recompile standard packages, and one is 
not so silly to try to deploy them in system32 - 
where one should not write anything since Windows 
2000 and maybe earlier - Embarcadero never noticed.
Embarcadero has the choice to help actual customers, 
or tell them to go to hell if they don't upgrade to 
each and every version.
As a marketing technique, I find it very silly. It's 
like get paying for your faults, not for your 
features...

Comment by Luigi D. Sandon on August 22, 20:50

Fix for Buffer Overflow in VCL Bitmap Processing Code 

 How safe is setting up a dummy project and
recompiling the graphics.pas and dependent units over
the old dcu files? - to fix for all projects.  Is
there a sample somewhere?

Comment by Stephen on August 25, 07:00

Fix for Buffer Overflow in VCL Bitmap Processing Code 

Luigi,

  I know you can dislike the scenario, but suggesting our users to 
replace our libraries (which I guess are signed) with different 
identically named ones on their customers systems would open for 
quite some severe security implications. You should know better, 
rather than using such arguments.

Microsoft wend all the way long to allow for side loading (same 
COM object with local registry overrides), I wonder it this should be 
an actual example. If you have an old unsupported version of .NET 
(and there are around) what's your best choice for a security issue 
in a past version?

There might be more things we can do, I'm not denying, and we 
can consider, but if you keep blaming us for anything that 
happens, it won't help much.

Comment by Marco Cantu [http://www.marcocantu.com] on August 25, 15:14

Fix for Buffer Overflow in VCL Bitmap Processing Code 

@Marco

More here

    
http://stackoverflow.com/questions/255550
09/f2051-unit-s-was-compiled-with-a-
different-version-of-s

Are you ready to believe that there's an 
issue yet or do we need to do more?

Comment by David Heffernan on August 28, 20:08

Fix for Buffer Overflow in VCL Bitmap Processing Code 

 Ok. That one appears to be fine. Seems 
to be certain units. Classes appears to 
be a problem. Ian Boyd seemed to succeed 
with Themes. You've succeeded with 
Graphics. 

Comment by David Heffernan on August 29, 09:52

Fix for Buffer Overflow in VCL Bitmap Processing Code 

A bit more on this. I'm using XE6 RTM, I didn't apply 
the update. Perhaps that's a difference. I can report 
that XE7 seems not to have the problems. So, perhaps 
it was just a transient oddity with one of the XE6 
releases. Perhaps the .dcu files you shipped with XE6 
RTM didn't quite match the source files that you 
shipped.  

Comment by David Heffernan on September 9, 10:15

Fix for Buffer Overflow in VCL Bitmap Processing Code 

 OK, just installed XE6 update 1 and the problem with 
Classes persists. No such problem in XE7 so whatever 
the fault was it appears to have been resolved.

Comment by David Heffernan on September 9, 12:37