Segfault on long memo fields

[Nigel kendrick]

I have one table where the user has pasted some notes from another
application into a 'comments' field of type 'memo' and mdb-export segfaults
when it gets to these notes - they are quite long and contain tabs.

I am not sure whether it's the length of the data or that it includes
non-ascii characters, but I just wondered if anyone had any ideas tracking
down the problem - I have had a look at the source code for mdb-export but I
don't know C very well so I'm not getting very far. I get the feeling it's a
buffer overflow or character (tab?) handling issue somewhere?

Any thoughts on where to look?

Thanks


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
mdbtools-dev mailing list
mdbtools-dev@...
https://lists.sourceforge.net/lists/listinfo/mdbtools-dev

[Brett Hutley]

Hi Nigel,

If it isn't sensitive data, can you upload a copy of the database somewhere? I can run it under the debugger, and see what's causing the segfault. It does sound like a buffer overflow problem to me too.

Alternatively, try building a debug version of mdb-tools and running it under gdb. That will show you where it is crashing.

Regards, Brett

On 23 Jul 2008, at 01:25, Nigel Kendrick wrote:

I have one table where the user has pasted some notes from another

application into a 'comments' field of type 'memo' and mdb-export segfaults

when it gets to these notes - they are quite long and contain tabs. 

I am not sure whether it's the length of the data or that it includes

non-ascii characters, but I just wondered if anyone had any ideas tracking

down the problem - I have had a look at the source code for mdb-export but I

don't know C very well so I'm not getting very far. I get the feeling it's a

buffer overflow or character (tab?) handling issue somewhere?

Any thoughts on where to look?

Thanks

-------------------------------------------------------------------------

This SF.Net email is sponsored by the Moblin Your Move Developer's challenge

Build the coolest Linux based applications with Moblin SDK & win great prizes

Grand prize is a trip for two to an Open Source event anywhere in the world

http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________

mdbtools-dev mailing list

mdbtools-dev@...

https://lists.sourceforge.net/lists/listinfo/mdbtools-dev

--

Brett Hutley [Head of Product Development, Stimuli Limited]

[b] brett@...  http://www.stimuli.org/

[h] brett@...   http://hutley.net/brett/

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
mdbtools-dev mailing list
mdbtools-dev@...
https://lists.sourceforge.net/lists/listinfo/mdbtools-dev

[Brett Hutley]

OK, the problem seems to be if the memo field is longer than MDB_BIND_SIZE bytes in length (defined in mdbtools.h and currently 16384), then the mdb_memo_to_string function in data.c fails. Specifically the function mdb_unicode2ascii in iconv.c does a copy from the source buffer to the dest buffer using the source length instead of the minimum of the source length & the dest buffer length (in case the destination buffer is too small).

I've attached a patch for data.c that should fix the problem. It increases the size of the "text" buffer if the memo is larger than MDB_BIND_SIZE bytes. I was wondering why the function always seems to allocate MDB_BIND_SIZE bytes though? It seems as though a little later in the function we actually read the size of the memo field, and we can then just allocate the right number of bytes directly. (Although I guess there is potentially a bit mask encoded in the length, which you'd need to mask out in order to get the actual length).

The fix to mdb_memo_to_string in iconv.c seems to be worth doing purely in terms of stopping buffer overflow issues, but it might be easier if the function is refactored a bit. Basically code like the following only addresses the problem in one place in the function, whereas it also exists in the else block of code following this, and I haven't checked the block of code dealing with compressed Unicode strings, or the #ifdef HAVE_ICONV block:

(Basically we strncpy the minimum of len_in and dlen):

--- iconv.c     7 Sep 2005 23:27:43 -0000       1.15

+++ iconv.c     24 Jul 2008 14:04:24 -0000

@@ -82,8 +82,11 @@

        dlen -= len_out;

 #else

        if (IS_JET3(mdb)) {

-               strncpy(out_ptr, in_ptr, len_in);

-               dlen = len_in;

+               size_t copy_len = len_in;

+               if (copy_len > dlen)

+                       copy_len = dlen;

+               strncpy(out_ptr, in_ptr, copy_len);

+               dlen = copy_len;

        } else {

                /* rough UCS-2LE to ISO-8859-1 conversion */

                unsigned int i;

Regards, Brett

On 23 Jul 2008, at 01:25, Nigel Kendrick wrote:

I have one table where the user has pasted some notes from another

application into a 'comments' field of type 'memo' and mdb-export segfaults

when it gets to these notes - they are quite long and contain tabs. 

I am not sure whether it's the length of the data or that it includes

non-ascii characters, but I just wondered if anyone had any ideas tracking

down the problem - I have had a look at the source code for mdb-export but I

don't know C very well so I'm not getting very far. I get the feeling it's a

buffer overflow or character (tab?) handling issue somewhere?

Any thoughts on where to look?

Thanks

-------------------------------------------------------------------------

This SF.Net email is sponsored by the Moblin Your Move Developer's challenge

Build the coolest Linux based applications with Moblin SDK & win great prizes

Grand prize is a trip for two to an Open Source event anywhere in the world

http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________

mdbtools-dev mailing list

mdbtools-dev@...

https://lists.sourceforge.net/lists/listinfo/mdbtools-dev

--

Brett Hutley [Head of Product Development, Stimuli Limited]

[b] brett@...  http://www.stimuli.org/

[h] brett@...   http://hutley.net/brett/

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
mdbtools-dev mailing list
mdbtools-dev@...
https://lists.sourceforge.net/lists/listinfo/mdbtools-dev

[Alex Hunsaker]

On Thu, Jul 24, 2008 at 8:14 AM, Brett Hutley <brett@...> wrote:
> I've attached a patch for data.c that should fix the problem. It increases
> the size of the "text" buffer if the memo is larger than MDB_BIND_SIZE
> bytes. I was wondering why the function always seems to allocate
> MDB_BIND_SIZE bytes though? It seems as though a little later in the
> function we actually read the size of the memo field, and we can then just
> allocate the right number of bytes directly. (Although I guess there is
> potentially a bit mask encoded in the length, which you'd need to mask out
> in order to get the actual length).

Sweet this patch also happens to fix this segfault I was getting (not
related to memo fields just a text column).

Thanks a lot Brett!

*** glibc detected *** mdb-export: munmap_chunk(): invalid pointer:
0x0000000000883f00 ***
======= Backtrace: =========
/lib/libc.so.6[0x7ffd8e87bff8]
/usr/local/lib/libmdb.so.1(mdb_col_to_string+0x201)[0x7ffd8ee25521]
/usr/local/lib/libmdb.so.1[0x7ffd8ee25bd8]
/usr/local/lib/libmdb.so.1(mdb_read_row+0x1cb)[0x7ffd8ee25eab]
/usr/local/lib/libmdb.so.1(mdb_fetch_row+0x81)[0x7ffd8ee25f81]
mdb-export[0x401538]
/lib/libc.so.6(__libc_start_main+0xe6)[0x7ffd8e8263f6]
mdb-export[0x400dd9]

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
mdbtools-dev mailing list
mdbtools-dev@...
https://lists.sourceforge.net/lists/listinfo/mdbtools-dev