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
.

Relevant Pages

  • About the function inet_ntoa()
    ... one for client and one for server. ... int argc; ... {struct sockaddr_in cin,cin2; ... char buffer; ...
    (comp.unix.programmer)
  • Re: [leds-pca9532] Add gpio capability
    ... version where gpio capability is optional. ... struct mutex update_lock; ... pca9532_data *data, int n_devs) ... static int pca9532_configure(struct i2c_client *client, ...
    (Linux-Kernel)
  • sending strings using winsock API
    ... I have a struct: ... int sourceID; ... This struct is defined on both the client and the server side. ... which is stored in a string variable. ...
    (comp.programming)
  • [PATCH] go7007: Convert to the new i2c device binding model
    ... Attempt to instantiate an I2C client by ID, ... The client driver module will register ... int audio_main_div; ... struct s2250 *dec; ...
    (Linux-Kernel)
  • Re: gui design
    ... and this is the structure for a window so far: ... int handle; ... struct window *prev, *next; ... curses or SDL. ...
    (comp.unix.programmer)