PRB: Wrong ReDim Preserve caused by a bug in OLE automation after recent updates

[wqweto]

FYI, consider this VB6 code:

Option Explicit

Private Sub Form_Load()
    Dim v As Variant
    
'    v = Array()
    ReDim v(-1 To -1) As Variant
    Text1.Text = Text1.Text & LBound(v) & ", " & UBound(v) & vbCrLf
    
    ReDim Preserve v(0 To 0) As Variant
    Text1.Text = Text1.Text & LBound(v) & ", " & UBound(v) & vbCrLf
    
    ReDim Preserve v(0 To 1) As Variant
    Text1.Text = Text1.Text & LBound(v) & ", " & UBound(v) & vbCrLf
    
    ReDim v(5 To 5) As Variant
    Text1.Text = Text1.Text & LBound(v) & ", " & UBound(v) & vbCrLf
    
    ReDim Preserve v(10 To 10) As Variant
    Text1.Text = Text1.Text & LBound(v) & ", " & UBound(v) & vbCrLf
End Sub

Output on XP and Win8 before recent updates seems to be ok:

-1, -1
0, 0
0, 1
5, 5
10, 10

Output on Win8 after updates is slightly wrong:

-1, -1
-1, -1
0, 1
5, 5
5, 5

Apparently when no resizing is happening (no new memory is allocated) array bounds are not adjusted. On both Win8 machines MSVBVM60.DLL is version 6.0.98.15

cheers,
</wqw>

[LaVolpe]

Interesting. Don't have win8. Out of curiosity what happens when you add this to the final line?
Text1.Text = Text1.Text & VarType(v(10))

[Robert Rayment]

As well as your VB being affected, I found that KB300357, for the latest Win7 updates, prevented a help maker program (which I use for help in VB programs) from running. Uninstalling it fixed the problem.

[Robert Rayment]

Sorry that should have been KB3003057.

[wqweto]

On patched machines:

Run-time error '9':

Subscript out of range

... as expected

cheers,
</wqw>

[wqweto]

Sorry that should have been KB3003057.

This CU fixed a serious issue with WebBrowser control causing AVs on being unloaded that we (that is our clients) were affected severely by.

cheers,
</wqw>

[LaVolpe]

On patched machines:

Run-time error '9':

Subscript out of range

... as expected

cheers,
</wqw>

Well, if it applies to every win8 installation, kinda bites. Wonder what other things broke? Obviously the problem can be worked around, by resizing +1 then resizing -1. Gonna make it hard to assume the LBound/UBound isn't what you expected. Though coders, for the most part, don't directly access array elements by index, rather they loop thru them. However, can't be said for the 1st element of the array which is quite often checked by index. Again, bites

[LaVolpe]

FYI: for small arrays, resizing +1, then -1 not a big performance hit, but copying data 2x isn't optimal. For large arrays, really don't want to do this for performance reasons and a couple of APIs can be used to ensure LBound/UBound changes without copying a single array item:

Note: This can ONLY be used on dynamic 1D arrays that are not string arrays

' api declarations
Private Declare Sub CopyMemory Lib "kernel32.dll" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal Length As Long)
Private Declare Function VarPtrArray Lib "msvbvm60.dll" Alias "VarPtr" (ByRef Ptr() As Any) As Long

' sample call
    Dim v() As Variant
    Dim arrPtr As Long

    ReDim v(2014 To 2014)
    CopyMemory arrPtr, ByVal VarPtrArray(v()), 4& ' get location of array's structure
    ' change array to (10 to 10), change 10&, below, as needed
    CopyMemory ByVal arrPtr + 20&, 10&, 4& ' update the LBound member (UBound is dynamic)
    Msgbox "LBound = " & LBound(v) & vbnewline & "UBound = " & UBound(v)

[wqweto]

Actually I am sticking to 0 based arrays and (-1 To -1) hack I used to use for indication of uninitialized array. Nowadays I just use v = Array() and get a (0 To -1) array for free and later check for UBound(v) < 0 is the same in both cases. ReDim Preserve seems to work fine for (0 To -1) arrays even after latest OS updates.

Btw, this broken OLE API function affects Win7 and all of server variants too. So this is "endemic" problem not a Win8 only issue.

cheers,
</wqw>

[dilettante]

So if I understand the issue correctly, this provision seems to have been violated:

ReDim Statement

:
:

Similarly, when you use Preserve, you can change the size of the array only by changing the upper bound; changing the lower bound causes an error.

After the patch (whichever patch it is since KB3003057 is a blob of several patches) such invalid statements "succeed" but yield incorrect results (basically act as a no-op).

Does that sum it up?

[LaVolpe]

...such invalid statements "succeed" but yield incorrect results (basically act as a no-op).

Not so sure it's an invalid statement per this msdn quote

Resizing with Preserve. If you use Preserve, you can resize only the last dimension of the array. For every other dimension, you must specify the bound of the existing array.

For example, if your array has only one dimension, you can resize that dimension and still preserve all the contents of the array, because you are changing the last and only dimension. However, if your array has two or more dimensions, you can change the size of only the last dimension if you use Preserve.

[dilettante]

I don't see how that particular statement contradicts or invalidates the other one. You can only change the upper bound of the last dimension when using "Preserve."

[LaVolpe]

To be on the same page, referencing this article. That statement regarding changing lower bound & generating errors is only listed once & only after a sample multi-dimensional array, not 1D array. Obviously doesn't generate errors on WinXP & if no errors were generated on Win95+, then maybe we've been misinterpreting that 'rule' all along.

[dilettante]

Look at post #5 again.

That's the error you get when you (attempt to) change the lower bound with Redim Preserve... at least on machines without the patch package we're discussing.

[dilettante]

Ok, I'm crying "uncle" on this one.

This code:

Option Explicit

Private Sub Form_Load()
    Dim v As Variant

'    v = Array()
    ReDim v(-1 To -1) As Variant
    Text1.Text = Text1.Text & LBound(v) & ", " & UBound(v) & vbCrLf

    ReDim Preserve v(0 To 0) As Variant
    Text1.Text = Text1.Text & LBound(v) & ", " & UBound(v) & vbCrLf

    ReDim Preserve v(0 To 1) As Variant
    Text1.Text = Text1.Text & LBound(v) & ", " & UBound(v) & vbCrLf

    ReDim v(5 To 5) As Variant
    Text1.Text = Text1.Text & LBound(v) & ", " & UBound(v) & vbCrLf
    v(5) = 666

    ReDim Preserve v(10 To 10) As Variant
    Text1.Text = Text1.Text & LBound(v) & ", " & UBound(v) & vbCrLf
    Text1.Text = Text1.Text & CStr(v(10))
End Sub

... runs just fine on an unpatched machine, displaying the expected "666" at the end.

But on a patched machine you get an error 9.

[LaVolpe]

Ok, I'm crying "uncle" on this one.

Me too, until this thread came to life, I interpreted the 'rule' same as you. Only after seeing this thread, did I go back & critically read that article without presumptions

[georgekar]

In xp works as unpatched..

[wqweto]

@dilettante: ReDim Preserve statement works when changing lower bound *and* resizing the array, don't think you can explain this bug with the lack of clear documentation. Being able to change LBound is expected and probably the underlying API will be corrected in a future windows update as it's not only VB6 apps that are affected.

Someone on the OLE team decided to optimize SafeArrayRedim API call when array size is not changed (good for performance) and missed updating the new bounds in the last SAFEARRAYBOUNDs entry -- bad junior :-))

cheers,
</wqw>

[dilettante]

In xp works as unpatched..

Since XP is totally unsupported I'm not sure where you would get these IE patches for XP systems.

See Microsoft Security Bulletin MS14-065 - Critical where the supported configurations are listed. XP is not among them.

[dilettante]

@dilettante: ReDim Preserve statement works when changing lower bound *and* resizing the array, don't think you can explain this bug with the lack of clear documentation. Being able to change LBound is expected and probably the underlying API will be corrected in a future windows update as it's not only VB6 apps that are affected.

Already conceded the point, though I think the documentation is fairly explicit that this should not work. In any case it is what it is, I have no axe to grind. I just couldn't figure out from post #1 and post #5 what you were trying to tell us.

Someone on the OLE team decided to optimize SafeArrayRedim API call when array size is not changed (good for performance) and missed updating the new bounds in the last SAFEARRAYBOUNDs entry -- bad junior :-))

According to available information these are security patches and should not contain attempted "optimizations" anyway.

More likely we have yet another case of cheap labor being used to do things at Microsoft these days. Screwed up Patch Tuesdays are becoming routine from these guys.

[dilettante]

A Killer Combo: Critical Vulnerability and ‘Godmode’ Exploitation on CVE-2014-6332 offers more detail than I want or need.

XP machines are now a bigger hazard to others than ever before as trojan horse and botnet malware spreads using loopholes like this one.

[Magic Ink]

Dill and LaVolpe

A little clarification for us (me anyway) at the back of class please gents.

So if we stuck to the 'rule' apparently given in;

>Similarly, when you use Preserve, you can change the size of the array only by changing the upper bound; changing the lower bound causes an error.

.. believing that;

>changing the lower bound causes an error.

was true when in fact it was not true (and not ever having need to use or test it)

Our legacy Redim Preserve code is fine (at the moment!)

[Elroy]

WOW, lots of discussion I missed on this one. I read through as best I could.

But here's what I hypothesize is happening.

1) Array doesn't change number of elements: Nothing is changed (even if the bounds have changed in the Redim).

2) Array increases (or decreases) elements: The array is redimensioned appropriately. However, if the LBound has been changed, the value for the LBound is changed in the SafeArray structure, but none of the data is moved. The consequences of this is that the original data's indexes will appear shifted.

The following illustrates #2:

Option Explicit

Private Sub Form_Load()
    Dim v As Variant
 
    ReDim v(5 To 10) As Variant
    v(5) = "asdf"
    Text1.Text = Text1.Text & LBound(v) & ", " & UBound(v) & vbCrLf
    
    ReDim Preserve v(10 To 11) As Variant
    Text1.Text = Text1.Text & LBound(v) & ", " & UBound(v) & ", " & v(10) & vbCrLf
End Sub

I'm not sure I've ever tried to change a LBound on a Redim before, but this somewhat makes sense to me.

[dilettante]

Yes, changing the lower bound is OK even on Redim Preserve.

But if you try this in your programs running on a machine with the security patch package installed, the Redim Preserve seems to act as if the statement wasn't even there!

Option Explicit

Private Sub Form_Load()
    Dim V As Variant

    AutoRedraw = True

    Print "1. V(1 To 5): V(1) = ""Hello"""
    ReDim V(1 To 5): V(1) = "Hello"
    Print "2. LBound(V) is"; LBound(V); ", UBound(V) is"; UBound(V)

    Print "3. Redim Preserve V(0 To 4)"
    ReDim Preserve V(0 To 4)
    Print "4. LBound(V) is"; LBound(V); ", UBound(V) is"; UBound(V)
    Print "5. Print V(0) is ";
    On Error Resume Next
    Print V(0)
    If Err Then
        Print "*Failed, error is"; Err.Number; Err.Description
        On Error GoTo 0
        Print "5.a. Redim Preserve failed, V(1) still has "; V(1)
    End If
End Sub

[Elroy]

Yes dilettante, that's my condition #1 as outlined in post #23.

EDIT: It seems that, after the security patch, the Redim code is first testing if there is anything to do based on the single criterion of whether or not the number of elements have changed (overlooking the fact that the LBound (and consequently the UBound) may have changed without changing the element count).

[LaVolpe]

Dill and LaVolpe

A little clarification for us (me anyway) at the back of class please gents.

So if we stuck to the 'rule' apparently given in;

>Similarly, when you use Preserve, you can change the size of the array only by changing the upper bound; changing the lower bound causes an error.

.. believing that;

>changing the lower bound causes an error.

was true when in fact it was not true (and not ever having need to use or test it)

Our legacy Redim Preserve code is fine (at the moment!)

Appears what we believed was only true for multi-dimensional arrays.
Our legacy code appears only fine right now, depending on what patch was applied to the system, if not trying to ReDim Preserve from one LBound to another LBound while keeping the same number of elements. If changing the element count, then no issues

[Magic Ink]

LaVolpe: Thanks for that.

[wqweto]

http://www.kb.cert.org/vuls/id/158647

The Microsoft Windows OLE OleAut32.dll library provides the SafeArrayRedim function that allows resizing of SAFEARRAY objects in memory. In certain circumstances, this library does not properly check sizes of arrays when an error occurs (CVE-2014-6332). The improper size allows an attacker to manipulate memory in a way that can bypass the Internet Explorer Enhanced Protected Mode (EPM) sandbox as well as the Enhanced Mitigation Experience Toolkit (EMET).

I'm wondering how can I report a bug like this one with ReDim Preserve. Can't imagine how expensive it would be to fix it now that Windows All are patched. Connect?

cheers,
</wqw>

[georgekar]

This is the error that start 19 years...before???
From my Acorn Electron in 1984...always I use base 0 arrays and never change lower bound...So as I understand the problem appear when we redim preserving items and changing the lower bound.
So why Microsoft do that...and not fixing to the other..side? The other side is about the unsecured applications..I think that this is a sweeping..for old programs.

[Schmidt]

http://www.kb.cert.org/vuls/id/158647

I'm wondering how can I report a bug like this one with ReDim Preserve.

I don't think that the error is happening in Redim Preserve (SafeArrayRedim)
directly, because it only happens on "naked, non-array-defined Variant-Hulls".

E.g. when you change in dilettantes last example #24, the declaration of:

Dim V As Variant

to a real (direct) SafeArray-Declaration as:

Dim V() As Variant

or

Dim V() As String

...then appropriate errors are thrown already in the Redim Preserve Line (no ignoring of that line takes place).

So it has to be related to using Redim Preserve in *combination* with a Variant-Hull which then
serves as an additional layer of indirection, when dealing with the SafeArray-Pointer (at Offset 8).

Olaf

[Magic Ink]

So going back to the VB6 help for Redim we see and appreciate that;
The ReDim statement is used to size or resize a dynamic array that has already been formally declared using a Private, Public, or Dim statement with empty parentheses (without dimension subscripts).

[Elroy]

Yeah George and Magic,

I've actually long proposed that Microsoft should implement something like an "Option Redim Explicit" if they ever get smart and release a VB7.COM. It'd make a dim before a Redim mandatory, rather than letting a Redim define an array.

[Magic Ink]

> It'd make a dim before a Redim mandatory, rather than letting a Redim define an array.
A side issue with the case in point (ref post #1), I think, because an error occurs (as documented in Redim help when change of the lower bound is attempted) in the line 'ReDim Preserve v(0 To 0) As Variant' if we delete the line 'Dim v As Variant' and let Redim fall into 'declarative' mode.

[LaVolpe]

A side issue with the case in point (ref post #1), I think, because an error occurs (as documented in Redim help when change of the lower bound is attempted) in the line 'ReDim Preserve v(0 To 0) As Variant' if we delete the line 'Dim v As Variant' and let Redim fall into 'declarative' mode.

An error did not occur. For us old-timers that misinterpreted the shoddy MSDN documentation, we assumed changing the LBound would generate an error, it does generate errors only for multi-dimensional arrays. The link I referenced in post#13 has some really intriguing "Caution" info regarding variants

[Elroy]

In my mind, all the convolution discussed in the link of post #13 makes the case for an "Option Redim Explicit" that much stronger. I wouldn't even object to an "As Whatever" being disallowed on a Redim. I don't use them anyway. The "type" should just always be what the original "Dim" declaration declared it to be.

I'm actually "sort of" okay will allowing the LBound to change, so long as they're clear about what it's doing (and it would be a bit more consistent). Clearly, from the above, it's just "re-indexing" the array without actually shifting any data. In other words, the low side of the array never has more space created on it (and nor does it ever truncate data). And to flesh out being "more consistent", I think the LBound should be changeable even if the array size doesn't change (which clearly isn't presently the case).

But all of this is certainly nothing more than blowin' in the wind.

[tmonfort]

Sorry that should have been KB3003057.

Actually I had the same problem at work and I've been able to find the guilty KB => KB3006226.
When installed, the second ReDim has no effect on the boundaries.
When I uninstall it, the second ReDim changes the boundaries.
When I reinstall it, the second ReDim has no effect on the boundaries.

Code I tested:

Public Sub test()
Dim a As Variant
ReDim a(-1 To -1) As Variant
ReDim Preserve a(0 To 0) As Variant
MsgBox UBound(a) & " " & LBound(a)
End Sub

[dilettante]

Yeah, this has basically become a time bomb that might blow up any existing application at any time.

New programs shouldn't be a problem as long as they have been developed on a system with these "security" patches applied, because the distorted behavior will no longer work there during testing. Programs that need something like this can use some sort of workaround.

The problem is existing code developed earlier, or code subsequently developed on an XP system (which should never be done anymore anyway).

[tmonfort]

Yeah, this has basically become a time bomb that might blow up any existing application at any time.

New programs shouldn't be a problem as long as they have been developed on a system with these "security" patches applied, because the distorted behavior will no longer work there during testing. Programs that need something like this can use some sort of workaround.

The problem is existing code developed earlier, or code subsequently developed on an XP system (which should never be done anymore anyway).

Of course, new programs will be developed to avoid this configuration, but they have chances to have to handle this case specifiquely, which will make the code more obscure.
For this specific change, I cannot accept it. It's because, when you ask ReDim to keep the same size and just change the boundaries, you expect it to be done. There's, because of this change, an inconsistency in the semantics of ReDim. For me it's nothing else than a bug of the VB API, Microsoft has to fix asap.
Moreover (and it's my case), what about the applications that were in UAT phase before the deployment of this KB, and that have gone live after ?... Surprise to the users, and to production support.

Btw, I want to thank you all because This forum helped me a lot to find the KB.

Cheers

[dilettante]

I wasn't excusing it, just saying that it is only a "ticking time bomb" for existing code (both source and compiled).

This isn't a bug in VB6 at all, but a bug introduced into Windows (OLE) by the misguided Internet Explorer team, which "owns" far too much of Windows these days. The Office team has also done a great deal of damage to VB6 by taking control of quite a few of the OCXs originally shipped with VB6, the ADO libraries, etc.

Basically Microsoft is in chaotic self-inflicted decline these days. Far too little gets properly tested before being released anymore.

[dilettante]

See OLE broken after Cumulative Security Update for Internet Explorer KB3003057 for another time bomb.

As suggested there, about the only way to get attention would be:

There are several customers have reported the issues after installing KB3003057. You can post feedback at https://connect.microsoft.com/IE , this will be seen by the IE team.　

Thanks for your understanding.

Regards,

Lany Zhang (MSFT)

But unless you express it as an IE problem they will probably ignore your feedback. As I said, Microsoft is a seriously decaying organization now.