Using record extension for keylogging - Xwindows

This is a discussion on Using record extension for keylogging - Xwindows ; Hi, what do you think about fact, that it is very easy to catch keystrokes using Record Extension? Writing keylogger is very easy. I posted simple example on my blog: gniazdowski.blogspot.com/2008/01/xfreexorg- keylogger.html. Using included code it is easy to steal ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Using record extension for keylogging

  1. Using record extension for keylogging

    Hi,
    what do you think about fact, that it is very easy to catch keystrokes
    using Record Extension? Writing keylogger is very easy. I posted
    simple example on my blog: gniazdowski.blogspot.com/2008/01/xfreexorg-
    keylogger.html. Using included code it is easy to steal passwords and
    other sensitive data. AFAIK there is also second extension that allows
    that -- XEvIE. Shouldn't both those extensions be more secure? Other
    questions:

    1. Is it possible to list all X Record Extension clients?
    2. Is it possible to block new connections to X Record Extension
    without unloading the extension?

    --
    Regards,
    Mariusz

  2. Re: Using record extension for keylogging

    mg wrote:
    > Hi,
    > what do you think about fact, that it is very easy to catch keystrokes
    > using Record Extension? Writing keylogger is very easy. I posted
    > simple example on my blog: gniazdowski.blogspot.com/2008/01/xfreexorg-
    > keylogger.html. Using included code it is easy to steal passwords and
    > other sensitive data. AFAIK there is also second extension that allows
    > that -- XEvIE. Shouldn't both those extensions be more secure? Other
    > questions:
    >
    > 1. Is it possible to list all X Record Extension clients?


    Not as far as I know, unless xrestop would list that.

    > 2. Is it possible to block new connections to X Record Extension
    > without unloading the extension?


    I doubt it, unless you have a protocol filter. xmon is an example of a
    tool that might be useful for the basis of such a program.

    X wasn't really designed with security in mind IMO. It seems like
    security was added as an afterthought. Some of the features of X are
    also potential security problems. You can use InputOnly windows in
    theory to steal input as well. The fact that other clients can query
    the tree of other clients, and read and manipulate their properties
    can be problematic. Unfortunately other window systems share this
    problem too.

    The way X selection works is also really really not ideal, and I doubt
    most people would deny that these days.

    According to the X12 documents they are getting closer to some kind of
    better design.

    http://www.x.org/wiki/Development/X12


    In my OpenNexX window system (which is currently broken) but has worked
    in the past (I'm rewriting bits of it now). There is no event
    redirection. The WM can be replaced in the server. Other clients are
    not capable of reading the input for a specific client.

    The server-side window struct is like this:
    struct nx_window {
    struct nx_system *sys;
    unsigned int flags;

    int x, y;
    int rotate;
    int xscale;
    int yscale;
    int update;

    size_t map_file_size;
    struct nx_image *image;
    struct nx_event *buttonpress;
    struct nx_event *buttonrelease;
    struct nx_event *keypress;
    struct nx_event *keyrelease;
    struct nx_event *motion;

    struct nx_window *previous, *next;

    struct nx_window *focusnext; /* Used in the focus list. */

    int id; /* used by nx_server */
    char filename[PATH_MAX];
    int fd;

    void *wm_desktop;
    };


    The client-side window struct is like this:
    struct nx_client_window {
    int x;
    int y;
    char is_client_side;
    int id; /* server-id */
    struct nx_image image;
    char filename[PATH_MAX];
    int fd;
    struct nx_client *client;

    struct {
    int width, height;
    } request;

    unsigned int event_flags;
    struct nx_client_event buttonpress;
    struct nx_client_event buttonrelease;
    struct nx_client_event keypress;
    struct nx_client_event keyrelease;
    struct nx_client_event motion;

    void *manager_data; /* Private data for use by the geometry manager. */
    void *master_manager_data; /* Private data for the geometry manager
    parent. */
    void (*request_size) (struct nx_client_window *win, int width, int
    height);
    void (*free_manager_data) (struct nx_client_window *win);

    struct nx_client_window_destroy_callback *destroy_callbacks;
    struct nx_client_redraw_callback *redraw_callbacks;

    struct nx_client_window *parent;
    struct nx_client_window *children;

    struct {
    int flag;
    int count; /* The disabled count */
    } update;

    dlinkedlist;
    };




    There are no children of a client toplevel, unless they are client side.
    So, there is much less sharing going in. As far as a client is
    concerned it has an RGBA buffer that is mmap MAP_SHARED memory. So the
    client writes to the RGBA buffer, and may create subwindows with memory
    from malloc that get client-side composited. Each client window has a
    filename associated with it, within a /nexx directory (typically a
    tmpfs).

    It was meant to be all modular, but now I'm rethinking that.

    Video drivers run as separate processes that communicate via shared
    memory and a pipe with the nx_server, and each driver implements a test
    mode.

    The windows in the tree are automatically double-buffered. The client
    calls nx_update(window); Which causes the nx_server to read() (to avoid
    a race and possible segfault due to a malicous client truncating the
    file) from the shared memory mapped file to a secondary buffer. That
    secondary buffer is then composited when the tree of server-side windows
    is composited.


    OpenNexX was largely influenced by papers I've read about window systems
    like Rio, 8 1/2, and a paper by James Gosling about how he would design
    a window system these days IIRC written around 2002.

    There's a lot left to do, and I hope to someday be able to replace X,
    but it's difficult when people want OpenGL, and the ability to run games
    like Quake fast. The more I learn with this project, the more I learn
    about other things I can learn about that may help.

    I'm half pondering rewriting the majority of the C in a different
    language that is more dynamic, safer, and would allow for easier
    debugging, and introspection.


    George

  3. Re: Using record extension for keylogging

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    >>>>> mg writes:

    mg> Hi,
    mg> what do you think about fact, that it is very easy to catch keystrokes
    mg> using Record Extension? Writing keylogger is very easy. I posted
    mg> simple example on my blog: gniazdowski.blogspot.com/2008/01/xfreexorg-
    mg> keylogger.html. Using included code it is easy to steal passwords and
    mg> other sensitive data. AFAIK there is also second extension that allows
    mg> that -- XEvIE. Shouldn't both those extensions be more secure? Other
    mg> questions:

    It seems, you wiped off your blog, getting 404 here.

    - --
    Ashish Shukla आशीष शुक्ल http://wahjava.wordpress.com/
    ·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- --
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHlEdKHy+EEHYuXnQRAv4iAKCcXMqiBwEzRGt7UNxVI7 emTHC48wCgvF53
    LoB3nGh5j51K/PejfNqDmN4=
    =z1w4
    -----END PGP SIGNATURE-----

+ Reply to Thread