Thread Subject:

Undocumented Matlab vulnerability

In yesterday's post on http://www.isdpodcast.com/2010/01/08/episode-42/ , it was mentioned that:

"Matlab R2009b is subject to an Array Overrun (code execution) vulnerability. The main problem exist in dtoa implementation. Matlab has the same dtoa as Mozilla, OpenBSD, MacOS, Google, Opera etc. PoC code is available."

Does anyone have access to the PoC (Proof-of-Concept code) or to details pertaining Matlab? Also, is MathWorks planning a hotfix patch?

Yair Altman
http://UndocumentedMatlab.com

"Yair Altman"
> In yesterday's post on http://www.isdpodcast.com/2010/01/08/episode-42/ , it was mentioned that:
>
> "Matlab R2009b is subject to an Array Overrun (code execution) vulnerability. The main problem exist in dtoa implementation. Matlab has the same dtoa as Mozilla, OpenBSD, MacOS, Google, Opera etc. PoC code is available."
>
> Does anyone have access to the PoC (Proof-of-Concept code) or to details pertaining Matlab? Also, is MathWorks planning a hotfix patch?
>
> Yair Altman
> http://UndocumentedMatlab.com

I found this link:
http://seclists.org/fulldisclosure/2010/Jan/124

Oleg

Dear Oleg, Yair!

> I found this link:
> http://seclists.org/fulldisclosure/2010/Jan/124
> Oleg

This kills 2008b and 2009a also.
Thanks! Is it necessary to send a bug report? Jan

Here it is. Sorry for the delay.

http://www.mathworks.com/support/bugreports/

Bug report number 611546

---Bob.

"Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message
news:hib40q$mnh$1@fred.mathworks.com...
> Dear Oleg, Yair!
>
>> I found this link:
>> http://seclists.org/fulldisclosure/2010/Jan/124
>> Oleg
>
> This kills 2008b and 2009a also.
> Thanks! Is it necessary to send a bug report? Jan
>

Dear Bobby,

> Here it is. Sorry for the delay.
>
> http://www.mathworks.com/support/bugreports/
> Bug report number 611546
> ---Bob.

> > This kills 2008b and 2009a also.

I appreciate, that this bug is fixed. Thanks!
As far as I understand, this serious bug is fixed in 2010b, while all earlier versions keep this vulnerability.

My computer administrator is absolutely *not* satisfied with the possibility of getting admin privilegs by a batch driven program. He suggests two solutions:
1. Run Matlab in a virtual machine without internet connection - unfortunately without intranet-connection also.
2. Buy 10 licenses of 2010b and pay 3 workers for 3 month to perform a complete check of our test data set. If the results differ from tests with 2009a (and there have been tiny differences ever), the programs need some modifications and a new verification test. I assume, when these tests are finished, 2011a is available with new fixed bugs and the payed money is not spent, but burnt.

I'd suggest the only valuable solution:
Please publish bugfixes for old Matlab versions also. If it is to costly for TMW to support a bunch of old versions, please pick *one* old version and offer a long-term support with fixes of serious bugs only.

Running Matlab in an environment with demands for reliability and security is getting nearly impossible, if bugs are fixed for new versions only - because new versions *ever* include new bugs!
Therefore I repeat it another time: A long term supported version of Matlab would be a great advantage.

Kind regards and thanks for listening, Jan

Not a bad idea, you should contact your sale representative about this.

---Bob.


"Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message
news:i656cp$8l1$1@fred.mathworks.com...
> Dear Bobby,
>
>> Here it is. Sorry for the delay.
>>
>> http://www.mathworks.com/support/bugreports/
>> Bug report number 611546 ---Bob.
>
>> > This kills 2008b and 2009a also.
>
> I appreciate, that this bug is fixed. Thanks!
> As far as I understand, this serious bug is fixed in 2010b, while all
> earlier versions keep this vulnerability.
>
> My computer administrator is absolutely *not* satisfied with the
> possibility of getting admin privilegs by a batch driven program. He
> suggests two solutions:
> 1. Run Matlab in a virtual machine without internet connection -
> unfortunately without intranet-connection also. 2. Buy 10 licenses of
> 2010b and pay 3 workers for 3 month to perform a complete check of our
> test data set. If the results differ from tests with 2009a (and there have
> been tiny differences ever), the programs need some modifications and a
> new verification test. I assume, when these tests are finished, 2011a is
> available with new fixed bugs and the payed money is not spent, but burnt.
>
> I'd suggest the only valuable solution:
> Please publish bugfixes for old Matlab versions also. If it is to costly
> for TMW to support a bunch of old versions, please pick *one* old version
> and offer a long-term support with fixes of serious bugs only.
>
> Running Matlab in an environment with demands for reliability and security
> is getting nearly impossible, if bugs are fixed for new versions only -
> because new versions *ever* include new bugs! Therefore I repeat it
> another time: A long term supported version of Matlab would be a great
> advantage.
>
> Kind regards and thanks for listening, Jan
>

Dear Bobby,

> > Please publish bugfixes for old Matlab versions also. If it is to costly
> > for TMW to support a bunch of old versions, please pick *one* old version
> > and offer a long-term support with fixes of serious bugs only.

> Not a bad idea, you should contact your sale representative about this.

:-) I took any chance to repeat the idea of a long term supported version.

For scientific reasons a stable version would be obviously a great advantage. But what about the financial interests of TMW? Do customers pay less money, if they use a long term supported version and do not buy new ones?
Let me explained the current situation in a lab I'm working for: They run a homemade "long term support" version of Matlab 6.5.1: each failing toolbox function is shadowed by an improved M- or Mex-File. After years of disucussions with the admins, the local TMW representatives and the programmers they have decided to buy 2009a, but they still do not use it currently due to the risc of incompatibilities. If they start to use it, they won't use new features in the first year to allow crosschecking the code with 6.5.1! Finally it is clear, that they will not buy 2009b, 2010a, 2010b, 2011a etc. The lab does have an improved version of SPRINTF (6.5.1) -- but the bugs of SPRINTF (2009a) are fixed in 2010b, and the bugs of 2010b are fixed in 2012a!?

My conclusion: "no long term support" means (for some customers) "no support" and in consequence "no money".

Kind regards, Jan

> My conclusion: "no long term support" means (for some customers) "no support" and in consequence "no money".
>
> Kind regards, Jan

Releasing a stable version as of date X can be coupled with a tech support that releases patches with bug fixes for bugs found in new versions of matlab. This way a customer can buy the stable version and subscribe to the patch service.

It would be a commercially sustainable solution and it will meet the stability requests (with reputation benefits)

I don't see why TMW doesn't put an effort into a long term stability project instead of redirecting this kind of requests to the commercials...

Oleg

Jan,

I don't know much about the finanical side of stuff. But I think it is at
least good feedback to say exactly what you want from TMW. Given enough
customers demand, who knows what can happened.

---Bob.

"Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message
news:i67ru8$45j$1@fred.mathworks.com...
> Dear Bobby,
>
>> > Please publish bugfixes for old Matlab versions also. If it is to
>> > costly for TMW to support a bunch of old versions, please pick *one*
>> > old version and offer a long-term support with fixes of serious bugs
>> > only.
>
>> Not a bad idea, you should contact your sale representative about this.
>
> :-) I took any chance to repeat the idea of a long term supported
> version.
>
> For scientific reasons a stable version would be obviously a great
> advantage. But what about the financial interests of TMW? Do customers pay
> less money, if they use a long term supported version and do not buy new
> ones?
> Let me explained the current situation in a lab I'm working for: They run
> a homemade "long term support" version of Matlab 6.5.1: each failing
> toolbox function is shadowed by an improved M- or Mex-File. After years of
> disucussions with the admins, the local TMW representatives and the
> programmers they have decided to buy 2009a, but they still do not use it
> currently due to the risc of incompatibilities. If they start to use it,
> they won't use new features in the first year to allow crosschecking the
> code with 6.5.1! Finally it is clear, that they will not buy 2009b, 2010a,
> 2010b, 2011a etc. The lab does have an improved version of SPRINTF
> (6.5.1) -- but the bugs of SPRINTF (2009a) are fixed in 2010b, and the
> bugs of 2010b are fixed in 2012a!?
>
> My conclusion: "no long term support" means (for some customers) "no
> support" and in consequence "no money".
>
> Kind regards, Jan
>

Bobby Cheng wrote:
> Jan,
>
> I don't know much about the finanical side of stuff. But I think it is at
> least good feedback to say exactly what you want from TMW. Given enough
> customers demand, who knows what can happened.
>
> ---Bob.
...

Bob--_PLEASE_ don't toppost... :)

I think Jan's comments are very good and reflect a serious point that
imo also TMW doesn't consider strongly--compatibility.

It appears that while I'm sure TMW worries greatly about the
configuration management and software control of their own internal
codebase and release points that they really don't consider very much at
all that there are organizations that have production code of _their_
own upon which they are reliant and that introducing even the most
apparently benign of upgrades or modifications can have very major
impact on these customers.

--

dpb <none@non.net> wrote in message <i684gr$1qf$1@news.eternal-september.org>...
> Bobby Cheng wrote:
> > Jan,
> >
> > I don't know much about the finanical side of stuff. But I think it is at
> > least good feedback to say exactly what you want from TMW. Given enough
> > customers demand, who knows what can happened.
> >
> > ---Bob.
> ...
>
> Bob--_PLEASE_ don't toppost... :)
>
> I think Jan's comments are very good and reflect a serious point that
> imo also TMW doesn't consider strongly--compatibility.
>
> It appears that while I'm sure TMW worries greatly about the
> configuration management and software control of their own internal
> codebase and release points that they really don't consider very much at
> all that there are organizations that have production code of _their_
> own upon which they are reliant and that introducing even the most
> apparently benign of upgrades or modifications can have very major
> impact on these customers.
>
> --

I'm in the fortunate situation of having a very small number of simple MATLAB and LabVIEW applications to maintain, so I can update (I almost instinctively wrote "upgrade" but that reflects marketing as much as reality) to the latest versions with few worries.

Particularly for LabVIEW, some individual and corporate users have very large installed codebases (some of it controlling major instrumentation or industrial equipment) and are extremely hesitant to update even decade-old versions of their code, preferring to maintain old versions of the software and forgo new functionality and bug fixes.

It's a difficult problem, but I can also see why TMW and other software companies are reluctant to try to patch older versions. Maybe avoiding the unnecessary removal or deprecation of long-standing features is the best we can expect.

Oleg Komarov <oleg.komarovRemove.this@hotmail.it> wrote:
>> My conclusion: "no long term support" means (for some customers) "no
>> support" and in consequence "no money".
>>
>> Kind regards, Jan
>
> Releasing a stable version as of date X can be coupled with a tech
> support that releases patches with bug fixes for bugs found in new versions
> of matlab. This way a customer can buy the stable version and subscribe to
> the patch service.
>
> It would be a commercially sustainable solution and it will meet the
> stability requests (with reputation benefits)
>

I would pay for that. Pick a release, and tell me that bug fixes and
patches will be available for the next n years. If I don't need to use the
new features of a new release then I would really rather not have to
upgrade. Moving to a new version of MATLAB requires a lot of careful
testing.

This is why I stuck with MATLAB 6.5 for almost everything until last year.
Now that Solaris is no longer a supported platform I have had to migrate to
Linux. There were a lot of OpenGL related issues which made me shy away
from each new release, right through until R2009a. There have also been
java issues with the database toolbox, including R2010a. We track these
down and fix them, then upgrade and start over again. The java based
graphics can be a lot slower (factor of ten) than the non-java graphics,
but later versions of MATLAB do not support uimenus with the -nojvm startup
option.

If TMW would care to release a version of MATLAB for Solaris x86, I would
leap at it. Until then, though, I'll most likely stick with running R2009a
in a virtual machine. For what it's worth, I recommend using VirtualBox,
with Ubuntu 10.04 server as the guest OS. I have some notes on this:

http://www.quantmodels.co.uk/BuildVM.pdf

So, although it is well knonw that this isn't the place to vote for new
features, it is the place to encourage others to pester TMW for things. I
like what both Jan and Oleg have suggested, and will be sure to mention it
next time I am on the phone to TMW.


--
Dr Tristram J. Scott
Energy Consultant

Mark Shore wrote:
...

> It's a difficult problem, but I can also see why TMW and other software
> companies are reluctant to try to patch older versions. Maybe avoiding
> the unnecessary removal or deprecation of long-standing features is the
> best we can expect.

Agreed, and I certainly didn't intend to imply I thought it was/is a
simple conundrum TMW could avoid trivially.

In languages w/ formal Standards there's a process that has more than a
single vendor to control changes whereas w/ Matlab and/or similar
proprietary products it's their prerogative to make changes as they see
fit and customers either follow along or not. I don't say the TMW is
flippant about making changes but there's not a recourse that's similar
to other languages wherein there are multiple vendors as well as
freeware so that one isn't totally wedded to a single implementation.

W/ compilers, even w/ deprecated or obsolete features vendors tend to
continue to support the earlier modes as well excepting of course those
that have actual conflicting syntax or such, but even there there are
often switches to control compiler behavior. Consequently, one
generally has the benefit of at least most newer features as well as
earlier if required for compatibility which may eliminate the use of
some select advances.

The down side of the Standard process is, of course, that it is much
slower and less nimble so it doesn't lend itself to rapidly expanding
features nor does it handle the platform-specific issues of graphics
hardware or other niceties that tend to be the areas where the
single-vendor applications shine.

'Tis a conundrum indeed, agreed, for a vendor of TMW's ilk...

--

Dear dpb, dear readers,

> ... and reflect a serious point that
> imo also TMW doesn't consider strongly--compatibility.

The SPRINTF problem does not concern only compatibility, but it is a serious security problem. You can gain administrator privilegs! The fun stops at this level. I remember, that compiled Mex-files are not longer accepted in the FEX to improve the security. It would be necessary to forbid SPRINTF with dynamically created format strings also...

While my free AcrobatReader, IE, FireFox, Opera, Thunderbird, Linux, Open-Office, Java check daily for bugfixes concerning such serious exploits, TMW offers a lot of fixes only by buying a new version.

On the other hand you hit the point, dpb: If the new versions is perfectly compatible, the update costs just 500 to some thousands Euro, while for my lab the limited compatibility results in about 9 man*month to run the tests in addition.

Nevertheless, if compared to other complex software systems, the stability and compatibility of Matlab is much higher than the average. My programs designed for R11.1 (1999, Matlab 5.3.1) are to 99.9% compatible to 2009a. Let's compare Win98 with Vista (!without service packs!). Or try to get the file time with correct summer time with LCC 2.4 (shipped with Matlab). Or check, if the C99 standard (1999 also) is fully implemented in current C-compilers.
Fixing bugs in older versions (or at least *one* stable version, which could not be called "old" then anymore) is needed, not because Matlab is so buggy, but because Matlab is so valuable, stable and useful! The already reached level of quality demands for imrpoving the usability by maintaining existing releases. This is what I'm thinking of when I read TMW's mission:
http://www.mathworks.com/company/aboutus/mission_values/mission.html

Thanks and kind regards, Jan