Jump to content
Sign in to follow this  
floele

CDBurnerXP Security issue

Recommended Posts

Hi again,

I accidentially (no one bothered to tell me) noticed that a security issue within one of the components CDBurnerXP uses has been discovered. I've written a quick advisory about it: http://cdburnerxp.se/help/sa/1

Since it won't work with default security settings, its impact is limited though.

Share this post


Link to post
Share on other sites
Guest thx1200

Can you explain what the exploit is, what the impact is, and how it relates to CDBurnerXP in more detail? I read the linked KB and I understand that an arbitrary file can be written and run from within relaxed IE settings in the Intranet Zone, but when does this ActiveX (or an instance of IE) run within CDBurnerXP? I'm trying to get a handle for the risk of running CDBurnerXP and also what the "client requests of the software component" are you mention that is "by design" in your article.

Share this post


Link to post
Share on other sites
Can you explain what the exploit is, what the impact is, and how it relates to CDBurnerXP in more detail?

Those details are available on the website linked in the article.

but when does this ActiveX (or an instance of IE) run within CDBurnerXP?

It doesn't, and it doesn't need to.

I'm trying to get a handle for the risk of running CDBurnerXP

Basically, there is no risk (the last sentence says it) if you don't have risky security settings.

Share this post


Link to post
Share on other sites

Maybe I'm just a moron, but I still don't understand the relation of that component to CDBurnerXP. In your advisory, I see something about a "behavior is by design" -- what behavior, exactly? What does that have to do with CDBurnerXP? Additionally, the securityreason.com article is how to exploit NMSDVDX.dll, not what it does for CDBurnerXP. Nothing explains how this component relates to CDBurnerXP. An example would be, "NMSDVDX.DLL provides DVD writing capabilities to CDBurnerXP and is a required component" or "NMSDVDX.DLL is optional and only for situations x, y, and z, so if you can delete the file if you are very paranoid."

Also, do you happen to know if NMSDVDX.DLL will be fixed in the future? This is a pretty serious vulnerability only mitigated by IE's standard security model (which is good, but not ideal). Any component that can be hosted by a browser and allow arbitrary data to be written to the file system is Not A Good Thing.

Share this post


Link to post
Share on other sites
Maybe I'm just a moron, but I still don't understand the relation of that component to CDBurnerXP.

I added some information.

Also, do you happen to know if NMSDVDX.DLL will be fixed in the future?

The article says "no".

Share this post


Link to post
Share on other sites

I have to say that although the likelihood of "in the wild" exploit is small, there is still a risk. The "LogMessage" method should be augmented so that if it detects IE as a host, it will not allow file writing. I've written NuMedia directly to see what their reaction is.

Never underestimate the stupidity/ignorance of users. There are many forms of malware (disgusing itself as useful) that users readily install that greatly relax IE security settings during installation (after the user has elevated under Vista), which will make IE ripe for this type of attack by other malware loading the control via the CDBXP installation folder. The default configuration is safe. Heck, even a relaxed configuration is safe under Vista, since IE is sandboxed in Protected Mode, but there are many vulnerable computers out there where this can be potentially exploited.

I can't think of anything CDBXP can do directly to mitigate this problem other than what you've already done (the bulletin) and maybe pestering NuMedia to plug the hole. I guess mainly, I'm just saying, "don't blow it off because it's unlikely." :-)

Thanks for the great piece of software. I use it daily!

Share this post


Link to post
Share on other sites

They won't fix it (I asked them). And actually, numerous other components could be a threat if we always assume relaxed security settings. That doesn't make sense.

Share this post


Link to post
Share on other sites

Perhaps... But how many other web browser components provide a method that acts as an unfiltered gateway to the filesystem for scripts without a user prompt (such as a "save file" dialog)? If a MS component allowed this, it'd be big news. Right now it's just "security through obscurity." NuMedia really should fix this.

Share this post


Link to post
Share on other sites
Perhaps... But how many other web browser components provide a method that acts as an unfiltered gateway to the filesystem for scripts without a user prompt (such as a "save file" dialog)? If a MS component allowed this, it'd be big news.

Apparently, it's not. Because it is the Microsoft component which allows this kind of execution (execution within a webpage, that is). Is not a fault of our components.

Right now it's just "security through obscurity."

No, it's not. It's security through appropriate security settings.

Share this post


Link to post
Share on other sites

You can blame the platform (IE), sure. But the fact remains that a burning API is providing a scriptable mechanism to write arbitrary data to an arbitrary location in the file system. Why? Why does NuMedia open that can of worms? It's poorly designed from a security perspective. This is similar to the WMF exploit, only on a smaller scale. WMF contained features it didn't need to (left over from 16-bit Windows) that gave a graphical image format the ability to script out dangerous code and execute it, unbenownst to the user. Who expects opening an image file will execute a dangerous script that can wreak havoc on a system? Here we have a burning API doing a similar thing.

I suppose we'll have to agree to disagree. I think everybody should play ball when it comes to security and I am a strong proponent of Defense in Depth.

Share this post


Link to post
Share on other sites
But the fact remains that a burning API is providing a scriptable mechanism

That's what the burning library is about. If it doesn't have a COM-visible API, you can't use it!

to write arbitrary data to an arbitrary location in the file system.

I guess you would consider your burning device being remote controlled an issue as well. If we assume that the burning library's API is available for a website, there's a whole lot more that can be done than just this. For example, we could write ISO files to an arbitrary location. And the burning libray obviously cannot exist without such features/options.

I'm not playing down security issues here.

Share this post


Link to post
Share on other sites

If a script created a dangerous ISO file, it would still require you to burn that ISO to a disk and manually execute the dangerous content, which is two more steps required -- greatly increasing the scripting effort and time for a user to figure out what's going on (not to mention that you have to hope they have a blank CD already in the drive in addition to a low security IE in the first place).

Creating an arbitrary text file that contains script code that is malicious that can be executed all within a browser all at once without user intervention is more dangerous. I also don't really see how that feature helps a burning app. A burning app can use native file writing techniques to generate logs -- why does this have to be included in a DirectX control?

See the distinction?

I'm not advocating a lack of scriptable COM components - lord no! I write a lot of software that makes use of COM. COM rocks my world! That was a strawman argument. Not fair. I think I've been pretty fair in my discussion. If I haven't, please let me know. I'm just trying to point out that the particular feature being exploited here has more potential to do harm than good. That's all.

I agree this is a low-risk issue. But I still don't see why the method that's being exploited exists. I can't figure out why it's necessary to be in there.

Share this post


Link to post
Share on other sites
I agree this is a low-risk issue. But I still don't see why the method that's being exploited exists. I can't figure out why it's necessary to be in there.

This kind of discussion should be held with NuMedia though, not here ;)

Basically, that's what "their" users requested.

Share this post


Link to post
Share on other sites

Sorry to pollute your forum with their problem. I was just expressing some frustration with what seemed to be a potential legitimate security problem (however unlikely) and the feeling of "nobody caring."

Actually, I just got an email back from NuMedia. They explained in greater detail some of the mitigating factors required to get the exploit script to work (it seems quite a bit more complicated than the security bulletin made it sound) and I'm satisfied this is a non-issue. The security bulletin makes it seem as if only a few flipped flags in IE will enable the exploit, but in the wild there will be multiple layers of user confirmation before the COM control can be activated, even under ideal conditions, and that defeats the concerns I had that under lowered IE security it would just happen "automatically." Perhaps in IE5 it would be automatic, but IE6/IE7 and newer have more confirmation/warning dialogs in place than the exploit's description was leading to believe.

They also told me about the MessageLog method being a client request -- still a strange client request for the same reasons I listed above!

Thanks for the great product, Flo!

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.