Mailslots are another IPC mechanism offered by Windows. In contrast to named pipes, mailslots are neither connection-oriented nor bidirectional; clients simply send messages to a server process. Mailslot clients never read from a mailslot; only servers can (the server being the process that has a handle to the mailslot object). The limited functionality mailslots offer translates into much less work for code auditors. However, for the sake of completeness, the following sections run through some basics. Mailslot PermissionsMailslots don't have a unique set of access rights. Instead, they use the standard file access rights discussed in Chapter 11. Their permissions can be audited in the same manner as standard file permissions. Mailslot SquattingMailslot squatting isn't possible in the same way it is with most other named objects because mailslots have only a creation function, CreateMailslot(), which fails if a mailslot of the same name already exists. The client end of a mailslot is then opened with CreateFile(), which fails if you attempt to open a mailslot that doesn't exist. There's the possibility of a client sending messages to a server it didn't intend to. This error occurs when a malicious user creates the mailslot before the server, so when the server starts and fails to create a mailslot, it simply exits, leaving the malicious mailslot in the object namespace for clients to connect to. This attack allows the rogue application to impersonate the server and read messages from clients, which could result in an information leak. |