Locking files (both read and write) always allowed?

Ryan Fox rfox at noguska.com
Tue Jun 26 20:21:09 GMT 2001


Before I begin my response, let me preface it by saying that I assume the
behavior described is expected and by design, and that Samba is by far not
the only file sharing software vulnerable to this kind of attack.  If my
assumptions are incorrect, please flame me and go about your day.

Such a situation could easily be resolved (when you know a file is locked
with malicious intent) by killing the user's connection.  This can be done
in Samba by using smbstatus to find the pid of the connection, and using the
kill command.  This would be followed by disabling the user's account, and
locating a large object to beat them with.

Perhaps it would be a good idea to impliment controls in smb.conf to allow
limits on the max number of file locks per connection, as well as max time
length of locks.  This would allow a slightly more preemptive resolution to
more severe attacks of this type.  However, setting these options in the
default install, even to generous values, would surely break some
applications and result in more support questions.

Food for thought,
Ryan Fox


> Hi,
>
> (Before I start, don't worry [:PP] this has nothing to do with the oplock
problem I've
> explained earlier...)
>
> The (theoretical) problem is: every user can lock any file.
> I tested this with QBASIC (yeah!!) with an lowprivileged user,
> user has only read access to the share.
> when I do something like:
> (q: = networkdrive)
> --
> open "q:\apps\netscape\programs\netscape.exe" for random lock read write
as #1
> k$=input$(1)
> close #1
> --
> Nobody can start netscape anymore (!) until I hit a key.
>
> Is this the expected behavior?
> Does it break things when changed?
> In short: why is this possible, for me it's pretty dangerous when any user
> can lock the other XX users out of every program :P
>
> Ofcourse I can(/will have to) change the source, but just wanted to know
> if this can't be changed in future samba releases.
>
> Cya,
>
>     Syz.
>
>
>
>





More information about the samba-technical mailing list