old buffer overflow in moxa driver

[dann frazier]

hey,
I noticed that the moxa input checking security bug described by
CVE-2005-0504 appears to remain unfixed upstream.

The issue is described here:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0504

Debian has been shipping the following patch from Andres Salomon. I
tried contacting the listed maintainer a few months ago but received
no response.

I've tested that this still applies to and compiles against 2.6.21.

Signed-off-by: dann frazier <da...@hp.com>

diff --git a/drivers/char/moxa.c b/drivers/char/moxa.c
index 7dbaee8..e0d35c2 100644
--- a/drivers/char/moxa.c
+++ b/drivers/char/moxa.c
@@ -1582,7 +1582,7 @@ copy:

if(copy_from_user(&dltmp, argp, sizeof(struct dl_str)))
return -EFAULT;
- if(dltmp.cardno < 0 || dltmp.cardno >= MAX_BOARDS)
+ if(dltmp.cardno < 0 || dltmp.cardno >= MAX_BOARDS || dltmp.len < 0)
return -EINVAL;

switch(cmd)
@@ -2529,6 +2529,8 @@ static int moxaloadbios(int cardno, unsigned char __user *tmp, int len)
void __iomem *baseAddr;
int i;

+ if(len < 0 || len > sizeof(moxaBuff))
+ return -EINVAL;
if(copy_from_user(moxaBuff, tmp, len))
return -EFAULT;
baseAddr = moxa_boards[cardno].basemem;
@@ -2576,7 +2578,7 @@ static int moxaload320b(int cardno, unsigned char __user *tmp, int len)
void __iomem *baseAddr;
int i;

- if(len > sizeof(moxaBuff))
+ if(len < 0 || len > sizeof(moxaBuff))
return -EINVAL;
if(copy_from_user(moxaBuff, tmp, len))
return -EFAULT;
@@ -2596,6 +2598,8 @@ static int moxaloadcode(int cardno, unsigned char __user *tmp, int len)
void __iomem *baseAddr, *ofsAddr;
int retval, port, i;

+ if(len < 0 || len > sizeof(moxaBuff))
+ return -EINVAL;
if(copy_from_user(moxaBuff, tmp, len))
return -EFAULT;
baseAddr = moxa_boards[cardno].basemem;

--
dann frazier
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Alan Cox]

> I noticed that the moxa input checking security bug described by
> CVE-2005-0504 appears to remain unfixed upstream.
>
> The issue is described here:
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0504
>
> Debian has been shipping the following patch from Andres Salomon. I
> tried contacting the listed maintainer a few months ago but received
> no response.

case MOXA_LOAD_BIOS:
case MOXA_FIND_BOARD:
case MOXA_LOAD_C320B:
case MOXA_LOAD_CODE:
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
break;

At the point you abuse these calls you can already just load arbitary
data from userspace anyway.

[Ismail Dönmez]

On Tuesday 01 May 2007 02:04:55 Alan Cox wrote:
> > I noticed that the moxa input checking security bug described by
> > CVE-2005-0504 appears to remain unfixed upstream.
> >
> > The issue is described here:
> > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0504
> >
> > Debian has been shipping the following patch from Andres Salomon. I
> > tried contacting the listed maintainer a few months ago but received
> > no response.
>
> case MOXA_LOAD_BIOS:
> case MOXA_FIND_BOARD:
> case MOXA_LOAD_C320B:
> case MOXA_LOAD_CODE:
> if (!capable(CAP_SYS_RAWIO))
> return -EPERM;
> break;
>
> At the point you abuse these calls you can already just load arbitary
> data from userspace anyway.

So the possible exploit will only work when run by root, is that what you
mean? If so isn't that still a security problem?

Sorry if I misunderstood what you said.

Regards,
ismail

[Andres Salomon]

Wow, I'd forgotten all about this one.

Signed-off-by: Andres Salomon <dili...@debian.org>

-

[Jiri Slaby]

Alan Cox napsal(a):

>> I noticed that the moxa input checking security bug described by
>> CVE-2005-0504 appears to remain unfixed upstream.
>>
>> The issue is described here:
>> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0504
>>
>> Debian has been shipping the following patch from Andres Salomon. I
>> tried contacting the listed maintainer a few months ago but received
>> no response.
>
>
> case MOXA_LOAD_BIOS:
> case MOXA_FIND_BOARD:
> case MOXA_LOAD_C320B:
> case MOXA_LOAD_CODE:
> if (!capable(CAP_SYS_RAWIO))
> return -EPERM;
> break;
>
> At the point you abuse these calls you can already just load arbitary
> data from userspace anyway.

The problem is that we BUG_ON, when len < 0 in copy_from_user which is unlikely
something we want to cause?

regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E

[Andres Salomon]

Jiri Slaby wrote:
> Alan Cox napsal(a):
>>> I noticed that the moxa input checking security bug described by
>>> CVE-2005-0504 appears to remain unfixed upstream.
>>>
>>> The issue is described here:
>>> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0504
>>>
>>> Debian has been shipping the following patch from Andres Salomon. I
>>> tried contacting the listed maintainer a few months ago but received
>>> no response.
>>
>> case MOXA_LOAD_BIOS:
>> case MOXA_FIND_BOARD:
>> case MOXA_LOAD_C320B:
>> case MOXA_LOAD_CODE:
>> if (!capable(CAP_SYS_RAWIO))
>> return -EPERM;
>> break;
>>
>> At the point you abuse these calls you can already just load arbitary
>> data from userspace anyway.
>
> The problem is that we BUG_ON, when len < 0 in copy_from_user which is unlikely
> something we want to cause?
>
> regards,

Right; the lack of input checking is most definitely a bug. It's no
longer a security issue, as a CAP_SYS_RAWIO check was added at some
point to the code path, but it's still a bug.

[Alan Cox]

> > At the point you abuse these calls you can already just load arbitary
> > data from userspace anyway.
>
> So the possible exploit will only work when run by root, is that what you
> mean? If so isn't that still a security problem?

To exploit the hole you need CAP_SYS_RAWIO which is the highest
capability of all. CAP_SYS_RAWIO gives you the ability to access hardware
directly so since it checks for CAP_SYS_RAWIO it isn't security.

The patch isn't wrong however and adds some sanity checking so it would
do no harm to send it to Andrew for -mm testing.

Alan

[Jiri Slaby]

On 5/1/07, Alan Cox <al...@lxorguk.ukuu.org.uk> wrote:
> > > At the point you abuse these calls you can already just load arbitary
> > > data from userspace anyway.
> >
> > So the possible exploit will only work when run by root, is that what you
> > mean? If so isn't that still a security problem?
>
> To exploit the hole you need CAP_SYS_RAWIO which is the highest
> capability of all. CAP_SYS_RAWIO gives you the ability to access hardware
> directly so since it checks for CAP_SYS_RAWIO it isn't security.

I understand that, but without it, the driver might seem buggy as far
as the person with permissions can write bad values and cause BUG().
On the other hand if the user has CAP_SYS_RAWIO, he has access to
/dev/{k,}mem anyway ;).

> The patch isn't wrong however and adds some sanity checking so it would
> do no harm to send it to Andrew for -mm testing.

Yes.

regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E

[dann frazier]

On Tue, May 01, 2007 at 04:29:27AM -0400, Andres Salomon wrote:
> Right; the lack of input checking is most definitely a bug. It's no
> longer a security issue, as a CAP_SYS_RAWIO check was added at some
> point to the code path, but it's still a bug.

I hadn't noticed this, but yes - the CAP_SYS_RAWIO check was added in
2.6.16.

--
dann frazier | HP Open Source and Linux Organization

[Andrew Morton]

I'm seeing copies of this patch floating around the internet from the 2.6.10
timeframe at least.

Could people please be more diligent about getting bugfixes back into
mainline?