DoS Flaws Found in Samba Module
On the odd chance people haven't seen this: http://www.eweek.com/article2/0,1759,1728956,00.asp German security researcher Stefan Esser has discovered multiple vulnerabilities in smbfs, the mountable SMB (Server Message Block) file system for Linux. In an advisory made public Wednesday, Esser said the bugs theoretically could crash the kernel or leak kernel memory with the help of the SMB server. The alert carries a moderately critical rating. The vulnerabilities have been corrected in Linux 2.4.28. A final patch for the 2.6 kernel is being developed. [remainder of story at web site referenced above] From what the story says, it appears to be confined to Linux, but it wouldn't hurt to check. Bart. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE : Compiling SAMBA with better options
| I quite agree with your remarks, but I fear that you seem to forget a very | important point : Samba/VMS is a port from a quite complicated software that | comes from Unix, and is quite often updated. If you multiply the #ifdef | for VMS specifics, you begin to have a lot of work each time a new release | comes in, if you want to follow the Unix updates. So I tend to limit the VMS | specific changes to truly functional ones, not for the intellectual benefit | of removing warning or informational messages. I do know where the code comes from, and I'm not proposing the addition of any #ifdef s at all. The modules that should be including STARLET.H are VMS only or are already conditionalized for VMS, because only VMS-specific code will be calling sys$open, sys$truncate, etc. As for the other warnings: they are indications of problems in the common code. Comparing an unsigned integer to a signed value is something that should not be done on any platform. The OpenVMS C compiler is warning of things that should be fixed on all platforms in the common code. | them on the Internet. I was not too much enthusiast, but I eventually | agreed, and since then I try to do my best to help other users who encounter | problems. May I say that since the beginning of this Samba/VMS version (more | or less 1 year ago), not a single problem was due to the /STAND=VAXC option | ? I'm sure your efforts are appreciated. Unfortunately, you can't be sure you don't have problems due to the compiler options. Compiling /STAND=VAXC means that warning messages about code that could be causing problems are not seen. You are also losing out on improvements the compiler can make to the code. I'm trying to make the results of my compilation run available to everyone who wants it. I hope someone would know how to pass back the information to the people who are 'responsible' for the common code so the major problems can be fixed. I also think the improved compiler switches would be good for everybody running on OpenVMS. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Compiling SAMBA with better options
I've been looking more at the source code and the way it's compiled. /STANDARD=VAXC is really not a good choice. It covers up too many real and potential problems in the code. I decided to try compiling with a better set of options which I have included below. (the /ARCH = HOST isn't essential, but it helps if the code is going to execute on the same architecture as it's compiled.) I got a lot of warnings about locally declared prototypes (PROTOSCOPE): these aren't always problems, but they can be if the function is used in more than one place. So I have (for now) told the compiler not to issue any warnings about that one particular potential problem. There are other checks that could be included in the /CHECK qualifier, and when the currently known problems are addressed perhaps a /CHECK or even a /CHECK=ALL should be done. There is also a question of what to do with names that are longer than 31 characters. I don't know what ANSI says about it, but they're a potential problem on OpenVMS. There is work going on to address this, but for now removing the /STANDARD=VAXC means usually choosing a method of dealing with names. I tried /NAMES = (AS_IS, SHORTENED) which shortens the names in a predictable manner. However, I got errors linking the executables because some names didn't match. I think /NAMES = (UPPERCASE, SHORTENED) would be better and I intend to try that. A lot of the code compiles cleanly with this set of options, which it should. When the compiler flags something, it's usually a real problem, and something which would be a problem on any platform. For example, there are many cases where an unsigned variable is being compared to a signed constant or value. I also edited two modules: [SAMBA-2_2_7A-SRC.SOURCE.VMS] VMS_SUPPORT.C for the previously discussed problem with getdvi instead of getdviw and [SAMBA-2_2_7A-SRC.SOURCE.SMBD] CLOSE.C because it calls sys$open, sys$close, etc. without the functions being defined. Modules that call these functions are better off if they #include starlet.h to define the function prototypes. There are a couple of other modules where this should be done. The compiler command I used is: $ cc := CC/DECC/NOLIST/INCLUDE=([],[.INCLUDE],[.UBIQX],[.SMBWRAPPER],[.tdb],[.popt],[.VMS]) - /DEFINE=(WITH_SMBPASSWD_SAM, HAVE_IFACE_IFCONF) /NESTED = PRIMARY - /ARCH = HOST /ASSUME = WHOLE /CHECK = (UNINIT, POINTER = ALL) - /LIST /CROSS /SHOW = BRIEF /PREFIX = ALL /OPT = LEVEL = 5 - /NAMES = (AS_IS, SHORTENED) /WARN = DISABLE = PROTOSCOPE The number of modules with warnings is longer than I would post to the mailing list by default (if you include the entire message, which includes a pointer to the code with an explanation). I can mail it, or you can pick it up from a web site. My personal web site is: http://encompasserve.org/~lederman/index.html There should be a pointer to samba1.txt and samba1.zip which has the results of my compilation. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE : Problem with VMS_SUPPORT.C
The disk on which I am testing (DISK$STORAGE) is ODS-5. Bart. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Problem with VMS_SUPPORT.C
I've been trying out the 2.2.7A kit on OpenVMS 7.3-1, and I've noticed a problem I don't think I've seen mentioned here. In the log.* file, I noticed there was a $GETDVI error after every file accessed. So I looked around the source for where it came from, and I see that the system call isn't coded properly in VMS_SUPPORT.C sts = sys$getdvi(0,0,dev,dvi_itm,iosb,0,0,0); I think should be sts = sys$getdviw(0,0,dev,dvi_itm,iosb,0,0,0); The wait version should be used to make sure the information comes back before the program proceeds to use it. Also, I think the addressing mode on the I/O status block was wrong. (I'm also not thrilled with the declaration of iosb, but that's a separate issue.) However, this doesn't fix the underlying problem. If you look at the error code, it translates to invalid device name. If you look at where dev is filled in, it calls vms_get_filespec, which includes an entire file name specification. I checked the manual, and the item codes being requested for GETDVI, MAXBLOCKS, FREEBLOCKS, and MAXFILES, apply only to devices, and not files. (Actually, I believe all of GETDVI applies only to devices and not files.) So before calling GETDVI you need to strip off everything but the device specification. Even so, this code doesn't make obvious sense to me. Why would you need to retrieve this information when reading files? I can see wanting to know how much free space remains on the disk before trying to WRITE a file, but none of this is needed when reading a file, and only FREEBLOCKS is of any use in telling you if there is sufficient space to write a new file. It seems to me that SAMBA is doing a lot of unnecessary work here. Suggestions? Bart. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Problem with VMS_SUPPORT.C
In case it wasn't clear, I'm still seeing erros after changing the call to what I posted in my first message: sys$getdviw and the correct addressing mode. The error message passed back says it's trying to do a GETDVI with a device name that in fact contains a file specification string. It should be just a device name without any file or directory information. This has absolutely nothing to do with logical names. A GETDVI call has to be fed a device name only. The code clearly indicates that it's being fed a file specification. I don't see how this call could ever have worked properly. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Time to add blocking to the mailing list?
I assume others have also seen the junk from [EMAIL PROTECTED] and similar addresses advertising something from http://www.szbookshop.com (though I'm not sure what, since it's in 8 bit characters). I've reported this through SpamCop, but I'm not sure it will do any good. The mail originates from a network in China, and according to SpamCop they ignore abuse reports, at least from SpamCop. My experience is that they ignore abuse reports from everyone. If the administrator of this mailing list can't get any response from them, or the system where the URL is, I propose that it's now time to block the source from submitting mail to to the mailing list. It appears to be the only way to deal with these people. (Unless someone can read the posts and says that they are in fact related to the SAMBA product we're discussing here.) Bart.
