Re: Advisory file locking support?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Hi Johannes,

Johannes Passing wrote:
Corinna Vinschen wrote:
Hmm, how likely is that? The advisory file locking is a cooperative
effort anyway. The object names are using subdirs in the global
namespace which you can't create using Win32 functions, so it's
unlikely that a normal Win32 process will ever accidentally create
such an object name.
Certainly not by accident, no. But say some process (server or whatever)
uses advisory locking. Any malicious program, even if running as a
restricted user, in a different session and not having access to the
respective files, can create those lock objects and trick the server.
Eventually, this might lead to the server blocking forever for those
locks to be released. Yes, it is unlikely, but I'd still consider it a
security risk. And the fact that there is no Win32 equivalent for
NtCreateDirectoryObject etc is hardly a protection... I do not know the
exact semantics POSIX requires, but I assume a process using advisory
locking may expect not to be subject to such DoS issues.

I didn't consider NtCreateDirectoryObject a protection against a
malicious application, just a protection against accidental creation of
such an object from Win32 apps. Still, a malicious application which
would use this advisory locking mechanism would have some problems:

- It would be malicious only to Cygwin processes, not to native Win32
processes or the machine as a whole.

- The locking objects only exist as long as some process has an open
handle to it. To be effective, the malicious application has to keep
running and as such is identifiable.

- It would have to know that certain files are subject to advisory
file locking.

- It would have to know that certain PIDs are Cygwin processes.

- It would have to copy the whole naming scheme to create object names
recognized as valid locking objects.

- If it's a Cygwin application using fcntl in a malicious way, it's
not different from any other POSIX applications doing mischief.

All in all, I can see much easier and much more efficient mechanisms
to create a DoS attack.

For instance, locking a file using LockFileEx is much more efficient
and has much more effect than to hack an advisory file locking scheme
used by some non-system DLL. IMHO.


Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
.

Relevant Pages

  • Re: Any race conditions involved on adding/mod users from different processes
    ... they perform some kind of advisory locking. ... regard to the locks. ... to any specific locking protocol used by a set of related applications ...
    (comp.os.linux.development.apps)
  • Advisory file locking support?
    ... Is there any support for *advisory* locking in the NT kernel, ... be accessible from Win32 user space processes? ... I'd like to implement advisory locking in Cygwin. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: PHP-Counter resettet immer wieder
    ... du lockst ein separates File (ein Lockfile) mit Advisory ... Locking, liest und schreibst anschliessend dein Counterfile und unlockst ...
    (de.comp.lang.perl.misc)
  • Re: Advisory file locking support?
    ... such an object from Win32 apps. ... The locking objects only exist as long as some process has an open ... It would have to know that certain files are subject to advisory ... But the point is that LockFileEx requires the malicious process to be granted access to the file. ...
    (microsoft.public.win32.programmer.kernel)
  • Module for better file locking. Name => "IO::Lock" ?
    ... I'm writing a module for file locking, with the intent that it be more ... lock_file(FILE, LOCKMODE) ... flock doesn't match the Win32 paradigm. ...
    (comp.lang.perl.modules)