The /dev directory is where the user interface to kernel device drivers and other <em> special files </em> are located. The UNIX kernel interface to devices such as modems, printers, disks happens using device drivers built into the kernel. User processes typically access devices (kernel device drivers) via special files. Many of the files are located in the /dev/ directory.
You ask, can someone gain root access via these files. To answer that we should define what root access means:
The UNIX <B> superuser </B> is a user with UID (user ID) 0 (zero) that are granted special privileges by the UNIX kernel. The login name for this user is normally "root" (it does not have to be). When a device file is called by a process and the process was run by the superuser, then the behavior of the device driver has special privileges. So, if a device driver had malicious code or a logic flaw that compromises the integrity of the system, the system can be compromised.
On many UNIX platforms, RAM is also managed via a special file, for example /dev/kmem (or something to that effect). A system vulnerability exists when this special file is world readable because clever people could read the system memory at any time. Reading system memory can compromise any system, not only UNIX but all systems.
The bottom line is that all files should have the proper permissions. Any file which runs as UID 0 has the potential for misuse. Remember the Stoll story about the C Egg? One of the methods used by the hackers was crontab files that are executed by the superuser process. When the root crontab file was found world writable, any process that is executed by the cron will execute as the superuser. Naturally, it is a very poor configuration management to leave these crontab files world-writable.
Files in the /dev directory can be the source of security breaches. Not all files are created nor executed equal. There are also files with permission that say 'set the UID of the calling user to 0' (SUID). When this flag is set, a file which is not owned by UID 0 gets the same privileges as the UID 0 user. All SUID 0 files require special precautions.