Re: [Full-Disclosure] M$ - so what should they do?
On Tue, 22 Jun 2004 09:04:37 +1200, Stuart Fox (DSL AK) [EMAIL PROTECTED] wrote: How about changing the .exe convention? Making a file executable by it's extension probably causes a lot of opportunities for problems, doesn't it? Also, the magic file names, like CON and AUX should go away. No way! Am I the only person who still uses copy con filename.txt to create scripts and such at the command line? Please tell me I'm not? I don't use it to create scripts, but I do use it. Frequently use the filehandles on unix boxen, too, for that matter. Who needs a fullscreen editor? ;) ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] M$ - so what should they do?
On Mon, June 21, 2004 8:09 pm, [EMAIL PROTECTED] said: The corollary, of course, is that I.T will become more expensive because people will have to bite the bullet and get people with more than one skillset, or more people. A common UI (e.g. POSIX or GNU) solves this... Diversity of systems, similarity of administration. The best of both worlds. :) -Eric ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] M$ - so what should they do?
The real reason for the registry is to make it difficult to copy an application from one machine to another. In other words, it's a copy proctection scheme. Remember in the days of Win 3.1, you could do that? It all broke in Win95 with the registry. now the key to transfering the application from one machine to another is also trasnfering the associated registy entries and values to the new machine also -aditya ÿÿ éb½êÞvë axZÞx÷«²ÚGb¶*'¡ó[kj¯ðÃæj)mªÿrÿ ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] M$ - so what should they do?
Also, the magic file names, like CON and AUX should go away. No way! Am I the only person who still uses copy con filename.txt to create scripts and such at the command line? Please tell me I'm not? CON and NULL should stay but COM, AUX and LPT should go away. i had a server in which the script kiddes got into the ftp server and made a COM1 folder on ntfs. had been a pain in neck to rename that folder - had to use linux with ntfs support! -aditya ÿÿ éb½êÞvë axZÞx÷«²ÚGb¶*'¡ó[kj¯ðÃæj)mªÿrÿ ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] M$ - so what should they do?
On Tuesday 22 June 2004 07:31, Aditya, ALD [ Aditya Lalit Deshmukh ] might have typed: CON and NULL should stay but COM, AUX and LPT should go away. i had a server in which the script kiddes got into the ftp server and made a COM1 folder on ntfs. had been a pain in neck to rename that folder - had to use linux with ntfs support! If memory serves, 2K+ has a POSIX toolset that lets you remove those privileged files. I know I tested it once, just to make sure it would work (though the server never got compromised). I don't think NT4 did though. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] M$ - so what should they do?
Well, lets see, moving away from the Registry (single point of failure) would be a good step. this should be done the first thing, however the registry has backups and other ways to recover from failures howevert the builtin failure machanisms are not sufficent Separating the operating system from programs would be great, I don't like the fact that everything and it's brother thinks it can or should dump files into the system directory. that is the admin responcibility to lock down the system dir and the app programmers that require write access to program files folder. the confiration can be stored in the user profiles or system profiles if need be but programs requiring access to programs files dir is the responcibility of the programmer What else is flawed? What other changes should be made? there are many small small things which would be great if they were changed like the some undocmented parameters n functions in the kernel etc etc -aditya ÿÿ éb½êÞvë axZÞx÷«²ÚGb¶*'¡ó[kj¯ðÃæj)mªÿrÿ ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] M$ - so what should they do?
On Mon, 21 Jun 2004 [EMAIL PROTECTED] wrote: No way! Am I the only person who still uses copy con filename.txt to create scripts and such at the command line? Please tell me I'm not? I think the intent is that con as a special filename in every directory has to go away - you'd still be able to use copy c:\something\con filename.txt (Remember, us Unix people have had to use /dev/tty and /dev/null and /dev/zero for 3 decades, and never minded that 'tty', 'null', and 'zero' didn't exist in every single directory) Does this really matter? On UNIX I can can use /dev/whatever in any directory and I have to have that access to make UNIX work. Not having /dev/null available in every directory breaks things, I rely on it being there... The OS controls my access, I assume Windows does the same thing. Maybe having magic names that don't start with '/dev' (i.e., some known prefix) is a mistake, but I think that's a minor issue. Personally, I think the design of the registry and having apps like a GUI and web browser intricately tied into the OS is a very bad design and is at the core of the problem. Another is that MS is a marketing company, so they do things to gain and keep market share. That's been discussed to no end ;-) Microsoft would come a long way, very easily, in security if they made it so that you usually run things as a user, not root or Administrator. Lindows has this wrong and if it gets popular, it will have similar problems. Unfortunately for MS, if they make things harder, Linux starts to look easier... Todd ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] M$ - so what should they do?
On Tue, 22 Jun 2004 02:37:22 EDT, Todd Burroughs said: Maybe having magic names that don't start with '/dev' (i.e., some known prefix) is a mistake, but I think that's a minor issue. Actually, this sub-thread is entirely about the fact that magic names aren't a minor issue - referencing con.txt or prn.txt gets some non-intuitive results. ;) pgpydyF0LHiQo.pgp Description: PGP signature
Re: [Full-Disclosure] M$ - so what should they do?
On Mon, 21 Jun 2004 21:52:36 MDT, Bruce Ediger [EMAIL PROTECTED] said: And you have to open them by path /dev/null. Just opening null won't hurt, unless the current directory happens to be /dev. Small nit: Actually, this may or may not be true. There is no *inherent* magic to the /dev directory - it's merely the traditional place such things get put. However, it doesn't matter *where* the file is - it's still a *real* file system entry and not an invisible magic entry... Consider that this *will* work: # cd ./tmp # ls -l /dev/null crw-rw-rw- 1 root root 1, 3 Jun 14 15:42 /dev/null # mknod null c 1 3 # ls -l null crw-r--r-- 1 root root 1, 3 Jun 22 11:51 null There you go - a 'null' device file in the current directory (Incidentally, stopping this sort of thing is why many/most/all Unixoids support a 'nodev' option on the 'mount' command). The point remains that on Unixoid systems, it's done in 2 steps. First, the path is resolved down to a final target object (dealing with any /, ., or .. that may be found along the way). Either you get handed a permission error along the way, or you're looking at an object that's visible to you. At that point, the *visible* opject is dealt with in an appropriate manner (regular file, a pipe, a reference to a physical device, and so on). (And yes, I *know* I glossed over a few details, such as the exact semantics of traversing a directory that doesn't have both the r and x bits, and the subtle distinction between the root inode of a mounted filesystem, and the inode of the directory that's the mount point... :) pgpnLVR4WOon1.pgp Description: PGP signature
Re: [Full-Disclosure] M$ - so what should they do?
like duh... have you _not_ heard of edlin ??? On Tue, 22 Jun 2004 09:04:37 +1200, Stuart Fox (DSL AK) [EMAIL PROTECTED] wrote: How about changing the .exe convention? Making a file executable by it's extension probably causes a lot of opportunities for problems, doesn't it? Also, the magic file names, like CON and AUX should go away. No way! Am I the only person who still uses copy con filename.txt to create scripts and such at the command line? Please tell me I'm not? ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html -- Mohit Muthanna [mohit (at) muthanna (uhuh) com] There are 10 types of people. Those who understand binary, and those who don't. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] M$ - so what should they do?
What would you suggest Microsoft do to improve ? Georgi Guninski wrote: i am replying to the whole m$ thread, nothing personal. m$ are so bad, so it is really difficult for them to get any worse, but this does not mean they are really getting better. they crossed the badness point of no return() long time ago. georgi ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] M$ - so what should they do?
redeisgn their products..the basic windows design is flawed and needs reworking for one thing..:) Michael Schaefer wrote: What would you suggest Microsoft do to improve ? Georgi Guninski wrote: i am replying to the whole m$ thread, nothing personal. m$ are so bad, so it is really difficult for them to get any worse, but this does not mean they are really getting better. they crossed the badness point of no return() long time ago. georgi ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html -- My Foundation verse: Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD. -- carpe ductum -- Grab the tape ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] M$ - so what should they do?
Well, lets see, moving away from the Registry (single point of failure) would be a good step. Separating the operating system from programs would be great, I don't like the fact that everything and it's brother thinks it can or should dump files into the system directory. What else is flawed? What other changes should be made? William Warren wrote: redeisgn their products..the basic windows design is flawed and needs reworking for one thing..:) Michael Schaefer wrote: What would you suggest Microsoft do to improve ? ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] M$ - so what should they do?
Anything specific? Obviously this isn't going to happen in the short term and even long term your statement doesn't say the specific issue you feel is in the basic windows design that you think is wrong? Is it virtualization of memory? Support of GUI interfaces? What? At the very least what is the top hitter you think needs to be addressed in technical specifics not something like IE sucks and which btw, isn't a basic windows design piece. When I think basic windows design I think core pieces, api level and lower, not interfaces that makes your britches itch. I ask this because there are a lot of people who go around complaining that Windows Sucks and that it is obvious why yet can't state one solid concrete thing let alone a solid concrete basic core Windows thing and how they think it should be redone. I am not saying there aren't things that do suck and I have been very vocal myself with MS concerning these things especially with Exchange and if you go back a few years to code red days you will find usenet posts from me blistering MS over the on by default paradigm they followed for so long. Yes they have issues, but what do you think they are that is so flawed in the basic design that takes a complete redesign. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William Warren Sent: Monday, June 21, 2004 11:05 AM To: [EMAIL PROTECTED] Subject: Re: [Full-Disclosure] M$ - so what should they do? redeisgn their products..the basic windows design is flawed and needs reworking for one thing..:) Michael Schaefer wrote: What would you suggest Microsoft do to improve ? Georgi Guninski wrote: i am replying to the whole m$ thread, nothing personal. m$ are so bad, so it is really difficult for them to get any worse, but this does not mean they are really getting better. they crossed the badness point of no return() long time ago. georgi ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html -- My Foundation verse: Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD. -- carpe ductum -- Grab the tape ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] M$ - so what should they do?
On Mon, Jun 21, 2004 at 11:05:14AM -0400, William Warren wrote: redeisgn their products..the basic windows design is flawed and needs reworking for one thing..:) This is a 100% ignition topic, but... the basic Windows design is one of the better things about Windows. Some of the features the kernel part has are still not implemented in Linux, for instance... What really sucks is the user space part. The more close to the user, the worse it gets. I'd be careful with statements like that. Yeah, it is really cool to criticize Windows (those cool Linux hacker guys do this too), but I hear such statements usually from folks which could not provide any arguments to support such claims. Sorry, no offence intended. Ondra +-+ |Ondrej Krajicek (-KO| |Institute of Computer Science, Masaryk University Brno, CR | |http://isildur.ics.muni.cz/~ondra [EMAIL PROTECTED]| ++ pgpvwxx1wucpb.pgp Description: PGP signature
RE: [Full-Disclosure] M$ - so what should they do?
How about making it so I can secure things on my machine from family members without having to setup a server to use Active Directory just to do that. How about not having to pay for Exchange Server just easily use and out of office reply. Since Outlook and Outlook Express are the default email clients for home users, how about being able to create separate user accounts like Pegasus has done for over 10 years. *** Dave D. Cawley | High Speed Internet | Facts are meaningless. You could use facts Duryea, PA | to prove anything that's even remotely true. (570)451-4311 x104 | -Homer Simpson [EMAIL PROTECTED]| *** URL = http://www.adelphia.net --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.708 / Virus Database: 464 - Release Date: 6/18/2004 ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] M$ - so what should they do?
On Mon, Jun 21, 2004 at 01:52:10PM -0400, Dave D. Cawley wrote: How about making it so I can secure things on my machine from family members without having to setup a server to use Active Directory just to do that. How about not having to pay for Exchange Server just easily use and out of office reply. Since Outlook and Outlook Express are the default email clients for home users, how about being able to create separate user accounts like Pegasus has done for over 10 years. Well, I am not sure whether you have to use Exchange just because you run Windows Server. Also, whether Outlook/Express is the default MUA is the matter of OEM. I am using Windows XP on my notebook and still I am happy with Mutt for e-mails. For home use, I would probably recommend Mozilla or Firefox/Thunderbird for ordinary users (if they'd refuse to use Microsoft stuff). Exchange, Outlook, Office, ... have nothing to do with design of the operating system. These are optional tools, offered by the same company. You don't have to use them. And when it comes to operating systems, I am really not very happy with the support the Linux Kernel offers for e-mails (just kidding). Ondra +-+ |Ondrej Krajicek (-KO| |Institute of Computer Science, Masaryk University Brno, CR | |http://isildur.ics.muni.cz/~ondra [EMAIL PROTECTED]| ++ pgpzp7pnl053a.pgp Description: PGP signature
Re: [Full-Disclosure] M$ - so what should they do?
On Mon, 21 Jun 2004, Michael Schaefer wrote: Well, lets see, moving away from the Registry (single point of failure) would be a good step. Separating the operating system from programs would be great, I don't like the fact that everything and it's brother thinks it can or should dump files into the system directory. How about changing the .exe convention? Making a file executable by it's extension probably causes a lot of opportunities for problems, doesn't it? Also, the magic file names, like CON and AUX should go away. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] M$ - so what should they do?
Ah see now I agree with both of these. Good points. For the first one, what do you propose as an answer? Obviously going to a bunch of separate text files you have to configure gets away from that single point of failure of a single registry but adds all sorts of management issues and having to chase all over to gather info about what is on your machine. What is the right answer to this one? The second one, I concur completely, get the App stuff out of the Windows folders. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Schaefer Sent: Monday, June 21, 2004 12:50 PM To: William Warren Cc: [EMAIL PROTECTED] Subject: Re: [Full-Disclosure] M$ - so what should they do? Well, lets see, moving away from the Registry (single point of failure) would be a good step. Separating the operating system from programs would be great, I don't like the fact that everything and it's brother thinks it can or should dump files into the system directory. What else is flawed? What other changes should be made? William Warren wrote: redeisgn their products..the basic windows design is flawed and needs reworking for one thing..:) Michael Schaefer wrote: What would you suggest Microsoft do to improve ? ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] M$ - so what should they do?
You don't need AD to have different user accounts... You have local accounts and you can permission the files and folders as you want based on those user accounts. No AD required. Type NET USER at the command prompt, that will show you all of the separate users that are already created on your local machine. Out of office notification tends to be a server based task but if you want to do it from your client and leave your client up and running while you are out of office, set up a simple client rule. That is all that is done when you set out of office, only you doing it on your client makes it client based instead of server based Setting up rules is pretty easy, sure not as easy as clicking on out of office but come on, it isn't like you are walking on glass to create a rule anyway. I believe OE does and I know Outlook does support multiple profiles. Alternatively I have my Outlook open right now managing some 8 email accounts. I am not sure I understand nor can get behind a single one of these complaints. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave D. Cawley Sent: Monday, June 21, 2004 1:52 PM To: [EMAIL PROTECTED]; William Warren Cc: [EMAIL PROTECTED] Subject: RE: [Full-Disclosure] M$ - so what should they do? How about making it so I can secure things on my machine from family members without having to setup a server to use Active Directory just to do that. How about not having to pay for Exchange Server just easily use and out of office reply. Since Outlook and Outlook Express are the default email clients for home users, how about being able to create separate user accounts like Pegasus has done for over 10 years. *** Dave D. Cawley | High Speed Internet | Facts are meaningless. You could use facts Duryea, PA | to prove anything that's even remotely true. (570)451-4311 x104 | -Homer Simpson [EMAIL PROTECTED]| *** URL = http://www.adelphia.net --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.708 / Virus Database: 464 - Release Date: 6/18/2004 ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] M$ - so what should they do?
I suggest they change the double click to a tripple click, and while we are at it how about making the default desktop walpaper something other than light blue. -KF How about changing the .exe convention? Making a file executable by it's extension probably causes a lot of opportunities for problems, doesn't it? Also, the magic file names, like CON and AUX should go away. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] M$ - so what should they do?
On Mon, June 21, 2004 12:07 pm, joe said: For the first one, what do you propose as an answer? Obviously going to a bunch of separate text files you have to configure gets away from that single point of failure of a single registry but adds all sorts of management issues and having to chase all over to gather info about what is on your machine. What is the right answer to this one? Having all the configs as text files in /etc works fine for Unix-like systems. You can use any editor to look at the config - no need for some proprietary editor (regedit). Automating config changes is as easy as writing a simple shell script. Each config is named after its application, so it's easy to know which is which, and if you need to restore an application, just install the app then copy your backup config file into place. As a matter of fact, an entire system can be restored by re-installing the apps and only restoring /etc (configs) and /home (user data) from backup. Try that on Windows. Have you ever had a successful Windows restore without a full system backup or without re-configuring everything from scratch? It is extremely difficult. Why? Because of the registry... The config file mess is an excuse made up by MS to sell the registry concept. The registry does not make it easier to manage application configuration. Instead, it makes it considerably more complex. The real reason for the registry is to make it difficult to copy an application from one machine to another. In other words, it's a copy proctection scheme. Remember in the days of Win 3.1, you could do that? It all broke in Win95 with the registry. -Eric ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] M$ - so what should they do?
On Mon, 21 Jun 2004 09:52:09 EDT, Michael Schaefer said: What would you suggest Microsoft do to improve ? They will improve if and only if actually improving (as opposed to making noises about improving) makes financial sense. pgpf9HZlZSrfm.pgp Description: PGP signature
RE: [Full-Disclosure] M$ - so what should they do?
How about changing the .exe convention? Making a file executable by it's extension probably causes a lot of opportunities for problems, doesn't it? Also, the magic file names, like CON and AUX should go away. No way! Am I the only person who still uses copy con filename.txt to create scripts and such at the command line? Please tell me I'm not? ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] M$ - so what should they do?
[SNIP} The second one, I concur completely, get the App stuff out of the Windows folders. Which includes IE. Thanks, Ron DuFresne ~~ Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation. -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] M$ - so what should they do?
Oh absolutely. I've said it before, they aren't coding for the common good of the people. They are a business, to think they would make changes for any other reason than financial gain is silly. However, without changes and improvement, they won't continue to grow and sell so they need to make changes. If I owned a large software business I wouldn't just make changes because philosophically they made me happy or someone else happy but wouldn't help the bottom line of the company at all. I don't think most honest speaking folks would say the same. Knowing the specifics of what people think need to be improved could help someone in the company who has been fighting for that exact improvement. Most times when I have spoken with MS Dev guys or QFE guys, they think the same thing I do or many others do, however they don't have enough customer comments to back them to get management to sign off on the change. Additionally giving ideas on HOW something should be improved tends to go a longer way than simply saying something sucks and needs to be improved. Finally, the number of requests they get for changes probably balances out to 25-30% actually being able to be kept as the others all cancel each other out in being equal and opposite requests. I see that on a small scale with just the few tools I write and I maybe get only 100-200 emails a week with requests. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, June 21, 2004 4:00 PM To: [EMAIL PROTECTED] Cc: Georgi Guninski Subject: Re: [Full-Disclosure] M$ - so what should they do? On Mon, 21 Jun 2004 09:52:09 EDT, Michael Schaefer said: What would you suggest Microsoft do to improve ? They will improve if and only if actually improving (as opposed to making noises about improving) makes financial sense. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] M$ - so what should they do?
Absolutely, I posted that same message in a MS specific listserv today. My comments were along the lines of treat it like a purchased app and set up a new team to rebuild the app from the ground up, all new code. That way all of the hidden nuggets waiting to bite people are gone and you can say from the ground up security is considered. Anything built on old legacy code can always be questioned as unsafe given the number of old issues that keep popping up even now. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ron DuFresne Sent: Monday, June 21, 2004 5:07 PM To: joe Cc: [EMAIL PROTECTED] Subject: RE: [Full-Disclosure] M$ - so what should they do? [SNIP} The second one, I concur completely, get the App stuff out of the Windows folders. Which includes IE. Thanks, Ron DuFresne ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] M$ - so what should they do?
I am not sure I agree with the first thing. Actually I think it helps in that it is easier for people to know something is executable veruss having to look at additional attributes to see if something is executable. I would argue against many of the other associations that exist however such as DOC and ZIP and such. However that doesn't make them executable, it just means that something will read them and execute them when fired. What security benefit do you see for the second thing? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Ediger Sent: Monday, June 21, 2004 3:31 PM To: [EMAIL PROTECTED] Subject: Re: [Full-Disclosure] M$ - so what should they do? How about changing the .exe convention? Making a file executable by it's extension probably causes a lot of opportunities for problems, doesn't it? Also, the magic file names, like CON and AUX should go away. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] M$ - so what should they do?
On Mon, 21 Jun 2004 16:06:43 CDT, Ron DuFresne said: [SNIP} The second one, I concur completely, get the App stuff out of the Windows folders. Which includes IE. Actually, just doing that one *alone* (splitting it out so it isn't entwined into the OS) would probably do more than anything else. But we're not likely to see that happen, not since the Microsoft witnesses swore on a Bible that IE was an integral part of the OS pgpGmemAHJ6gw.pgp Description: PGP signature
Re: [Full-Disclosure] M$ - so what should they do?
On Tue, 22 Jun 2004 09:04:37 +1200, Stuart Fox (DSL AK) [EMAIL PROTECTED] said: No way! Am I the only person who still uses copy con filename.txt to create scripts and such at the command line? Please tell me I'm not? I think the intent is that con as a special filename in every directory has to go away - you'd still be able to use copy c:\something\con filename.txt (Remember, us Unix people have had to use /dev/tty and /dev/null and /dev/zero for 3 decades, and never minded that 'tty', 'null', and 'zero' didn't exist in every single directory) pgp9z4tIvHqSM.pgp Description: PGP signature
Re: [Full-Disclosure] M$ - so what should they do?
On Mon, 21 Jun 2004 18:33:02 EDT, joe [EMAIL PROTECTED] said: Oh absolutely. I've said it before, they aren't coding for the common good of the people. They are a business, to think they would make changes for any other reason than financial gain is silly. However, without changes and improvement, they won't continue to grow and sell so they need to make changes. No.. It's without the *customer perception* of changes and improvement. That's a crucial point - they can get away with things like packaging up all the bug fixes and selling it to the customers as a new release only because they manage to spin it as new and improved. And remember - Microsoft knows how to do marketing and spin better than anybody End result is that if the PR campaign *saying* it's better is cheaper than actually making the product better, they'll go for the PR campaign pgput8ieSBTx7.pgp Description: PGP signature
RE: [Full-Disclosure] M$ - so what should they do?
I am not so much in agreement here. You say you can use any editor to look at the config and you don't need a proprietary editor. What you mean is you can use any editor that uses the file system API to open and display the config files. With the registry you can you use any editor that uses the registry API to open and display the configurations. I have written several registry editor type apps for customers, it is simply another API. For me writing a text editor is the same as writing a registry editor, in fact, the classes I put together treat them both very similarly from code use perspective. I don't like the idea really of any system that jams all of the stuff in the same place. You have worries of uniqueness and allowing access to the right files for the right people. Plus if something happens to that one place be it the registry or the /etc folder, you have the same resulting issue. However on the flip side, you do want something that is somehow tied together so auditing a system (or systems) isn't quite as harsh as scanning through directory after directory looking for all of the config files. So what would work. I actually like the idea of breaking everything out into individual folders, but then you need some centralized registration scheme so that for security sake, you can quickly ascertain what is going on. Is the answer some combination of what MS is doing with what is the answer on *nix? Admins can register something for the whole system, users can only register things for themselves. The registry simply maintains pointers to the true registration info held in the folders? 10 people on one machine all load the same app... Here is where the pain comes in. That could be a terrible waste of space and resources, but from a security standpoint, maybe they should all maintain all of their own info for each instance But now what about security updates? You would be updating 10 instances. Hmmm point/counterpoint. What wins? I think your copy protection scheme might be pushing it a bit. It isn't much more work to capture registry mods and apply them to other machines. One of my old jobs had a large part of my time making up software dist packages that did just that. You capture the reg changes made, you capture the file changes made, you throw it into a package to be deployed by SMS or the perl dist method of your choice. If they were intending that to be wholly magical and to block software copying, there wouldn't be APIs the public would have available to go into it. This is more FUD/conspiracy thinking. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Paynter Sent: Monday, June 21, 2004 4:31 PM To: [EMAIL PROTECTED] Subject: RE: [Full-Disclosure] M$ - so what should they do? On Mon, June 21, 2004 12:07 pm, joe said: For the first one, what do you propose as an answer? Obviously going to a bunch of separate text files you have to configure gets away from that single point of failure of a single registry but adds all sorts of management issues and having to chase all over to gather info about what is on your machine. What is the right answer to this one? Having all the configs as text files in /etc works fine for Unix-like systems. You can use any editor to look at the config - no need for some proprietary editor (regedit). Automating config changes is as easy as writing a simple shell script. Each config is named after its application, so it's easy to know which is which, and if you need to restore an application, just install the app then copy your backup config file into place. As a matter of fact, an entire system can be restored by re-installing the apps and only restoring /etc (configs) and /home (user data) from backup. Try that on Windows. Have you ever had a successful Windows restore without a full system backup or without re-configuring everything from scratch? It is extremely difficult. Why? Because of the registry... The config file mess is an excuse made up by MS to sell the registry concept. The registry does not make it easier to manage application configuration. Instead, it makes it considerably more complex. The real reason for the registry is to make it difficult to copy an application from one machine to another. In other words, it's a copy proctection scheme. Remember in the days of Win 3.1, you could do that? It all broke in Win95 with the registry. -Eric ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] M$ - so what should they do?
[SNIP} The second one, I concur completely, get the App stuff out of the Windows folders. Which includes IE. Actually, just doing that one *alone* (splitting it out so it isn't entwined into the OS) would probably do more than anything else. But we're not likely to see that happen, not since the Microsoft witnesses swore on a Bible that IE was an integral part of the OS But then of course if you look at it, it's just a set of com components in a few dll's and iexplore.exe is just the glue that binds them all together. It actually probably wouldn't be that hard to remove IE from the Windows folders - just move those dll's. Of course, since there are now so many MS applications that use those components for presentation, you could argue they are an integral part of the OS (that just means they should go into C:\program files\common files or somewhere like that). ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] M$ - so what should they do?
Having all the configs as text files in /etc works fine for Unix-like systems. You can use any editor to look at the config - no need for some proprietary editor (regedit). Automating config changes is as easy as writing a simple shell script. Each config is named after its application, so it's easy to know which is which, and if you need to restore an application, just install the app then copy your backup config file into place. As a matter of fact, an entire system can be restored by re-installing the apps and only restoring /etc (configs) and /home (user data) from backup. Try that on Windows. Have you ever had a successful Windows restore without a full system backup or without re-configuring everything from scratch? It is extremely difficult. Why? Because of the registry... The config file mess is an excuse made up by MS to sell the registry concept. The registry does not make it easier to manage application configuration. Instead, it makes it considerably more complex. The real reason for the registry is to make it difficult to copy an application from one machine to another. In other words, it's a copy proctection scheme. Remember in the days of Win 3.1, you could do that? It all broke in Win95 with the registry. You've got some valid points but there is one thing that you've overlooked - auditing. One of the(few) advantages that the registry does have is that you can configure auditing on individual keys, so that if you want to you can track who made changes and when. With text files, you simply don't have that option (of course you can audit changes to the entire file). Having said that, I've never actually met anyone who uses the registry auditing, but I'm sure they're out there. Some of your points are also a bit dubious - registry mods are mostly scriptable (except binary data - one of my big gripes with the registry), and I'm not sure that it makes application configuration any more or less complex - they each have their advantages and disadvantages. As for copying applications, the issues are a bit deeper than the registry - if it was just the registry it would be easy enough to export import the relevant keys (they are well structured). It tends to be more related to issues such as dll's needing to be registered etc. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] M$ - so what should they do?
[EMAIL PROTECTED] wrote: Actually, just doing that one *alone* (splitting it out so it isn't entwined into the OS) would probably do more than anything else. But we're not likely to see that happen, not since the Microsoft witnesses swore on a Bible that IE was an integral part of the OS Yep -- the DoJ defense has many long and nasty tentacles that will ensure shoddiness and ongoing bad design decisions in MS software for many years to come. Is this the first major case of insecurity by enforced legal defense? Perhaps our law schools need to introduce a new course: Software architecture priciples for Lawyers ?? Regards, Nick FitzGerald ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] M$ - so what should they do?
On Mon, 21 Jun 2004 18:39:10 EDT, joe [EMAIL PROTECTED] said: Absolutely, I posted that same message in a MS specific listserv today. My comments were along the lines of treat it like a purchased app and set up a new team to rebuild the app from the ground up, all new code. That way all of the hidden nuggets waiting to bite people are gone and you can say from the ground up security is considered. Anything built on old legacy code can always be questioned as unsafe given the number of old issues that keep popping up even now. On the other hand, remember that we're talking about 35-50 *million* lines of code here - that's a massive amount of rewriting that's not generating any useful income for the company while it's going on. (You unixoids - we're talking about something on the same scale as redoing the Linux kernel, XFree86, and Mozilla from the ground up, from scratch). Estimate how many programmer-years it took to do it the first time, read Fred Brook's The Mythical Man-Month and apply a suitable adjustment for second system effect (bonus points if you can figure out how much the second system effect added to the *first* time around ;). And then realize that all those programmers are basically a boat anchor until they get finished with the re-write Also, to fix many of the design issues will require changing so many APIs and break so many programs that make use of the old way of doing things that they'd lose backward compatability. For instance - getting rid of 'con' as a special file name would remove all those attacks that depend on 'con.txt' or similar not behaving the way you'd expect. On the other hand, every single program that assumes that 'prn' gets you the printer will get b0rked over It's not as simple as throw it out and start again - what's feasible for a student's semester project or a small company's small software package isn't as feasible when it's one of the largest sets of intertwined code ever written pgpEJL6Ryq46T.pgp Description: PGP signature
Re: [Full-Disclosure] M$ - so what should they do?
On Mon, 21 Jun 2004 18:42:44 EDT, joe [EMAIL PROTECTED] said: I am not sure I agree with the first thing. Actually I think it helps in that it is easier for people to know something is executable veruss having to look at additional attributes to see if something is executable. Which is why so many people don't enable 'show file extensions' and thus get bitten by the 'cutebabe.jpg.exe' attacks, right? :) pgpW6RUTAaiPu.pgp Description: PGP signature
Re: [Full-Disclosure] M$ - so what should they do?
On Mon, 21 Jun 2004 18:55:55 EDT, joe [EMAIL PROTECTED] said: You say you can use any editor to look at the config and you don't need a proprietary editor. What you mean is you can use any editor that uses the file system API to open and display the config files. With the registry you can you use any editor that uses the registry API to open and display the configurations. I have written several registry editor type apps for customers, it is simply another API. For me writing a text editor is the same as writing a registry editor, in fact, the classes I put together treat them both very similarly from code use perspective. Well.. given that the file system API you need is basically open(), read(), write(), close(), and maybe a few umask() and chmod() calls, plus any fcntl() or similar locking for some of the files. The bar is set *really* low here.. any editor really means *any* - vi, emacs, perl, awk - I've been forced into using sed, ed, and cat on occasion if /usr isn't available, and even the shell 'echo' operator and redirection a few times... ;) Of course, you're free to create your own API and classes on top of those very low level pieces but there's no requirement that you do so. pgpxK0kdJiBhO.pgp Description: PGP signature
Re: [Full-Disclosure] M$ - so what should they do?
Valdis Kletnieks said: It's not as simple as throw it out and start again - what's feasible for a student's semester project or a small company's small software package isn't as feasible when it's one of the largest sets of intertwined code ever written And that's the main point - the enemy of security isn't any given company/package/platform. It's complexity. Complexity guarantees that there will be flaws, that might be exploited, in any product. The only products with no reported vulnerabilities are small, low use products, and the main reason there aren't any reports is no-one's bothered to look. It's a principle that no matter how much effort is put into attempting to achieve perfection, not just six sigmas, it can't be achieved. Without perfection no-one, not just Business, can risk a monoculture ( just ask the U.S. Wheat farming industry ) 'Cos this isn't medicine, where acceptable losses can be estimated - who could guess the impact from a code flaw in the root servers? Or base code for HTTP handling? Or the privilege handling code in Windows? I believe Microsoft are making genuine efforts to improve their code. But even with billions in the bank to spend on it, they can't make it perfect. And in order to trust that their code can run EVERYTHING, that's what it'd have to be. The corollary, of course, is that I.T will become more expensive because people will have to bite the bullet and get people with more than one skillset, or more people. Of course, they could outsource.. ;-) Regards, tom. Tom Cleary - Security Architect In IT, acceptable solutions depend upon humans - Computers don't negotiate. This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] M$ - so what should they do?
On Mon, June 21, 2004 6:14 pm, Stuart Fox (DSL AK) said: You've got some valid points but there is one thing that you've overlooked - auditing. [...] Having said that, I've never actually met anyone who uses the registry auditing, but I'm sure they're out there. I actually knew a group who once tried to use Windows auditing. After working on it for months they gave up. I never got the full details of why, but apparently it doesn't work exactly as expected. Something to do with the fact that in some cases, it logs what you *could have done* rather than what you *actually did*. In other words, if in the audit logs, when it says it granted permission to do something, that doesn't mean you actually did it. Just that you were granted permission to do it, which to many implies that you did it. However, it wouldn't hold up in court as evidence of something having been done. It tends to be more related to issues such as dll's needing to be registered etc. Registered where? ;-) -Eric ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] M$ - so what should they do?
On Mon, 21 Jun 2004, joe wrote: I am not sure I agree with the first thing. Actually I think it helps in that it is easier for people to know something is executable veruss having to look at additional attributes to see if something is executable. I think that making the name of a file determine whether it counts as executable or not conflates two distinct properties: (i) name, (ii) executableness Don't most of the worms like Bagel and Netsky depend on this sort of thing? Naming a file xyz.pif or abc.scr makes it executable. Clearly the name making a file executable contributes rather dramatically to the ease of constructing email worms. Since so many extensions make a file executable, your point is basically wrong. You can't look at a file extension and know whether naming a file with that extension will cause Windows to consider it executable or not executable. What security benefit do you see for the second thing? Here, the second thing is getting rid of magic, in-every-directory device files like CON or AUX or an undocumented host of others. I don't happen to believe in the badness of magic files as such, merely that having some magic file names really confuses things. This property has caused problems over and over through the years: http://www.securityfocus.com/archive/1/322941/2003-05-25/2003-05-31/2 http://www.microsoft.com/technet/security/bulletin/ms00-017.mspx http://support.microsoft.com/default.aspx?scid=kb;en-us;256015 And probably others. The point is that a DIR (or whatever) doesn't show these magic files, but doing an open() works fine. It's an exception to a usual rule about how file names work. Clearly, as evidenced above, it causes problems over and over. Exceptional cases are bad. Note that Unix/Linux/Plan 9/others get this sort of thing correct. Magic files like /dev/null or /dev/tty show up when you run ls or do opendir()/readdir(). Yeah, they're magic in some sense or another, but they follow all the rules that other files follow with their names. And you have to open them by path /dev/null. Just opening null won't hurt, unless the current directory happens to be /dev. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] M$ - so what should they do?
On Mon, June 21, 2004 3:55 pm, joe said: I have written several registry editor type apps for customers, it is simply another API. For me writing a text editor is the same as writing a registry editor, in fact, the classes I put together treat them both very similarly from code use perspective. You missed one significant point, though. In my 15 years of computer programming, I have never *had* to write a text editor. Whereas, you have had to write *several* (your word) registry editors. And the only person who needs to know anything about a filesystem API is a compiler programmer. The rest of us mere humans use the standard library of open(), close(), read(), and write() commands if we want to access files programmatically. One more thing, because of the complexity of the registry and removing it from the filesysem, in Windows, you need to learn the filesystem API (whatever that means to you) to get at the filesystem, the registry API to get at the registry, the COM API if you want to communicate between processes, and several application-specific APIs to programmatically configure most applications. In Unix systems, it's all treated as files. You use a common interface to use them all - open(), close(), read(), write(). How much simpler can it be? And the simpler it is, the less margin for error. And the less margin for error, the less risk of exploit. And that means better security... something to think about. And before you say you *can* configure apps by directly editing the registry, removing the need to learn all of those unique APIs (although still leaving you without a nice local IPC interface), you'd better check your support agreement on that. Even Windows is not supported by MS if you directly edit the registry. Most app vendors say you're on your own too if you do that... So good luck! Any bad move in the registry is like open heart surgery. The box may never boot again - I know, I've done it more than once. 10 people on one machine all load the same app... Here is where the pain comes in. That could be a terrible waste of space and resources, but from a security standpoint, maybe they should all maintain all of their own info for each instance But now what about security updates? You would be updating 10 instances. Hmmm point/counterpoint. What wins? Wow, that is a problem. Thank God it simply doesn't exist on Unix systems. The system-wide configs go into /etc and the user-customized portions go into /home/username/.appname (remember earlier I said all you need to backup is /etc and /home to restore a Unix machine?). Users don't install their own applications because they simply cannot. If they want an app, they ask the sysadmin to give it to them. If you are the sysadmin, you install it in the system area and the users get access to it as required. Don't forget, Unix systems were multi-user over a decade before DOS was even conceived. All of these problems have long since been solved. The biggest problem with Windows is that it is a multi-user system built on a single-user foundation. (Yes, I know, the NT kernel was built from the ground up the be multi-user, but the system layout did not change to be consistent with that, so maintaining it still has the same problems.) I think your copy protection scheme might be pushing it a bit. It isn't much more work to capture registry mods and apply them to other machines. One of my old jobs had a large part of my time making up software dist packages that did just that. You capture the reg changes made, you capture the file changes made, you throw it into a package to be deployed by SMS or the perl dist method of your choice. If they were intending that to be wholly magical and to block software copying, there wouldn't be APIs the public would have available to go into it. This is more FUD/conspiracy thinking. Yes, yes. I know. I did electronic software distribution in a windows environment of several thousand machines for many years. We started with sysdiff (remember that?), and then moved on to the SMS Installer. And we used GHOST to take full images for mass deployment of desktops. I know a million ways to capture an installation difference. But how many home users do? It was meant to be a deterrent, not a 100% success. Remember that before the registry, we didn't need tools like sysdiff. Anyhow, all that noise aside, I think it's safe to say that whatever the registry was intended to be, it was a complete and utter failure. There are more headaches over trying to figure some part of the registry than there ever were worrying about all those lost .ini files. And for some reason, large Unix systems with thousands of users don't have any of these problems. Go figure... Back to the topic: What should they do? They should do like Apple did: stop trying to re-invent the wheel and adopt a tried-and-true model that works. The Unix-like systems are simply easier to manage and safer. And Apple has made them as easy to
