Re: "logical unit communication failure" c2scan NEC ND-4550A 1.07
scdbackup@gmx.net writes:
> Hi,
>
>> This was not a change made because it would be nice, it was made because
>> it became public information that anyone who could burn could change the
>> firmware. Security fixes sometime do have to be done quickly, evil
>> people do tend to jump on any opening in the time between a
>> vulnerability becoming public and being fixed.
>
> I am looking since quite a while for the particular
> and substantial security problems which one is said
> to have if one allows w-access to a CD/DVD writer.
As far as I understand Jörg, vendor-specific commands are often involved
in CD writing, and if they are filtered out, CD writing may not work
with certain devices -- this is the central point of his criticism.
On the other hand, the kernel cannot know if a particular
vendor-specific opcode is dangerous or not, as these could theoretically
change even with a firmware update of the drive or its serial number or
whatever, so the kernel filters them out.
Jörg also agreed that filtering generally were a good idea, but only
complained in a general way that the filters were insufficient, without
specifying a list of commands that would need to be allowed. He instead
asked the kernel developers to produce the list themselves, which
doesn't seem very reasonable; particularly if the list, according to
Jörg is under constant change.
> - Is there other stuff at risk besides my 60 Euro burner ?
> Is system security in general threatened by the extreme
> example
> chmod a+rw /dev/hdc (resp. /dev/sg0 with 2.4 ide-scsi)
That depends if users can obtain device nodes or setuid privileges by
mounting media from this drive.
> - If i am willing to risk my burner's health (which i do
> with any physical tray load, actually) what would you
> advise me to do:
> - run a self written setuid-root or sudo program on restrictive
> rights
> - allow generous access to /dev/hdc and use neither setuid
> nor sudo
Judging from the system security, setuid/sudo is always dangerous;
injecting ANY code into cdrecord would allow every user a root shell.
> I have to amend that i am experienced but not in the sense
> as Joerg or kernel programmers. I know my limits and am not
> 100% sure wether i could make a program that is setuid-safe.
That depends on the overall setup. If the setuid program does some
privileged operations and can then drop all of its privileges by means
of setuid() early, it's not very difficult.
If you however swap UIDs around with seteuid() as cdrecord does, you
MUST essentially write bug-free code and make extensive validations of
the environment to prevent problems. seteuid() is really only a
convenience tool to prevent accident access to data where the invoking
user has no access, but nothing that would improve security WRT getting
root shells.
--
Matthias Andree
Reply to: