Found, a new rootkit
Mike.McCarty at sbcglobal.net
Fri Apr 7 21:03:56 UTC 2006
Mikkel L. Ellertson wrote:
> Mike McCarty wrote:
>>>I fail the see the difference between the Linux driver for a serial
>>>port, and the DOS driver for COM ports, at least as far as security
>>>goes. Nether driver does anything unless there is a program
>>You are right, in regards to the software itself. The difference
>>is that MSDOS does not automatically install device drivers
>>for COM ports, whereas Linux does.
>>>accessing them. The fact that the serial driver is built in with
>>>MS-DOS, and may be loadable under Linux does not make much
>>There is no built-in serial driver in MSDOS. MSDOS sits on top
>>of the BIOS. The drivers themselves simply make BIOS calls.
>>Unless some software makes a call to the driver, then the
>>COM port just sits.
> Are you sure about that? As far as I know, the BIOS does not know
> about serial ports. The settings for I/O and IRQ for a COM port are
I am absolutely certain.
> part of DOS< and not a BIOS setting. You can change them, and swap
> COM1 and COM2, I have a DOS utility that does this around here
> somewhere. It will also swap around LPT settings.
MSDOS does *not* use interrupt driven I/O on those ports. It uses
BIOS calls, specifically INT 14h. For example, from Ralph Brown's
INT 14 - SERIAL - INITIALIZE PORT
AH = 00h
AL = port parameters
bits 7-5 data rate (110,150,300,600,1200,2400,4800,9600 bps)
bits 4-3 parity (00 or 10 = none, 01 = odd, 11 = even)
bit 2 stop bits (set = 2, clear = 1)
bits 1-0 data bits (00 = 5, 01 = 6, 10 = 7, 11 = 8)
DX = port number (00h-03h) (04h-43h for Digiboard XAPCM232.SYS)
Return: AH = line status (see AH=03h)
FFh if error on Digiboard XAPCM232.SYS
AL = modem status (see AH=03h)
Notes: default handler is at F000h:E739h in IBM PC and 100% compatible
since the PCjr supports a maximum of 4800 bps, attempting to
bps will result in 4800 bps
various network and serial-port drivers support the standard BIOS
functions with interrupt-driven I/O instead of the BIOS's
the 04/08/93 Compaq system ROM uses only the low two bits of DX
>>From what I remember, the IRQs are not enabled in ether OS until
> something opens the port. Once you open the port, both DOS and
> Linux process the IRQ. Both have code to handle buffer overrun.
MSDOS does not enable interrupts on the COM ports. The code is
all passive, driven by the application making read/write requests.
Linux drivers (the ones I am aware of) enable/disable interrupts
based on open/close requests. The fact that they *can* enable
means that there is a possibility of a defect causing them to
enable under incorrect circumstances. The BIOS and MSDOS have
no code to do that, so it can't be done inadvertently.
>>>can be more of a security risk. You never really know what is in the
>>>BIOS. It is probably safe, as long as you are careful about updates.
>>Whatever is in the BIOS, it is still there when Linux is loaded.
> It is still there, but Linux does not use the BIOS to access the
> hardware. Code that is not executed is not a security risk. DOS uses
Precisely. And unless an application invokes MSDOS, it will never
do anything to the serial port, nor will the BIOS.
>>Any time there is physical access, there is only *relative* security.
> This is very true. But the risk of hooking a modem to a Linux
> machine by itself is no greater then hooking one to a DOS machine.
If there is more code, there is more exposure. MSDOS has much less
code than Linux and the Linux drivers for the serial ports.
> The risk depends on the software you use to access the modem. Using
> a FAX sending program on Linux is a lot less risk then running PC
> Anywhere on a DOS machine. (Yes, there was a version for DOS.)
Certainly, PC anywhere is a serious security risk.
Please don't lecture me about systems programming for MSDOS, as I
wrote my first interrupt-driven serial port handler for MSDOS
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
More information about the users