xsane: Scan buffer overflow possible

From: Marian Eichholz (marian.eichholz@freenet-ag.de)
Date: Mon May 28 2001 - 08:39:59 PDT

  • Next message: Aristide Aragon: "Microtek, Net, NetBSD"

    Oliver Rauch wrote:

    > > I didn't want to ask, but the first scan logs looked like the backend
    > > still requests full blocks whatever would happen.
    >
    > ???
    > The what has this to do with xsane?

    You remember the discussion we had some weeks ago woth the EOF
    detection?

    If not, or it got lost: No worries, I'll cite the proof for Nick Lamb at
    the end.

    Summary: We found, that xsane requests data transfers, even if the
    remaining buffer will be overflowed.
    Particularly, it does not recalculate the "number of bytes" parameter
    (of sane_read()) for the last transfer(s).

    Thus, the backend must be implemented *very* carefully, if it does not
    want to inadvertantly smash XSane's heap, because it cannot know, that
    there is no remaining buffer without help of a limiting "number of
    bytes" parameter.

    Obviously, xsane 0.77 still behaves the same way, and it is great, that
    You announced to fix this issue.

    > > I don't know, if it matters, but when xsane-0.77 prompts for "overwrite
    > > existing file" the left button has no label/text.
    >
    > In wich language? I tested with german and english and everything is ok for me.

    I have a german locale (de_DE).

    > > [To be honest, I updated glibc and xfree and have/had some problems with
    > > the locales]
    >
    > This could be a reason. May be because the "Ü" in "Überschreiben".

    Hmmm... Freeamp has issues in it's GTK interface with umlauts. Well,
    I'll check it, but it's not important.

    Yours,

    Marian Eichholz

    - old mail follows here -----------------------------------------------
    [Subject:EOF buffer overflow with Xsane 0.76]

    Hi friends,

    since Nick asked me for an example: Here I have the proof for the buffer
    overflow with Xsane 0.76.

    I scanned a tiny area in 100 DPI and RGB. Here is the trace:

    [sm3600] mode=0, res=100, BC=[0,0], xywh=[2097,325,945,1181]
    [sm3600] getting parameters (234,99)...
    [sm3600] reading chunk 65536...
    [sm3600] ... line 98 (22932/5)...
    [sm3600] reading chunk 65536...
    [sm3600] cancel called...
    [sm3600] mode=0, res=100, BC=[0,0], xywh=[2097,325,945,1181]
    [sm3600] getting parameters (234,99)...

    The "65536" is the buffer size / transfer length, taht is given by the
    front end to sane_read().

    You can see, that there are only 22932 byte needed for the scan. If I
    wrote more than this amount, Xsane would badly, badly crash (or at
    least, behave *very* strange).

    Nevertheless, it requests 128KB of data at all, and the backend has no
    chance to see, that there is not that much room in the buffers.

    In my opinion, the frontend should request only 22932 bytes, because
    this is the size in the buffer, and the next (EOF) cycle should really
    request only 0 (zero) byte, because the buffer pointer points in fact to
    the first byte *behind* the buffer area.

    IMHO this is a real bug. No worries, the backend copes with that :-)

    --
    Source code, list archive, and docs: http://www.mostang.com/sane/
    To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
    



    This archive was generated by hypermail 2b29 : Mon May 28 2001 - 08:35:59 PDT