Yep. I wonder how insecure NT really is. It has the feel of an accident looking for a place to happen. Of course whoever really knows is not talking. There would have to be an enormous amount of satisfaction from finding and plugging the _last_ security hole in linux. With two exploits in Outlook published in the same week, I feel safer ignoring it and watching/. for the fix for the next one that gets loose in the wild without a prior announcement. Worked for the Love Bug. It took Microsoft three days for a search for I LOVE YOU to show anything on their web site.
Arggh. If the Code Segment is not marked readable, you cannot read the code. You can't jump into the stack. You can jump to a "far return address" that is stored in the stack. You can jump to an address in the Code Segment which just happens to be coincident with something in the Stack Segment.
With NO CONTEXT SWITCHES, there are 8000+ local code spaces, 8000+ global code spaces, 8000+ local data spaces, 8000+ global data spaces, 8000+ local stack spaces, 8000+ global stack spaces. All these code and data spaces. All independent. All in the same context. But the OS has to handle them. No OS wants to bother. They all effectively point code, data, and stack to the same memory with bounds set to all of memory. There are four protection levels, but only Multics that I am aware of has ever used more than two levels. The hardware design of the 80386 is targeted at a Multics-like OS. Current i386 code is using separate code data and stack spaces, with bounds checking on all references to memory. Unfortunately, code, data, and stack point to the same memory with the bounds being all of memory.
Speed. Loading a segment register is comparable to integer multiply, the instruction, not the addressing shortcut.
Unless Operating Systems, Language designers, and programmers are willing to give up the nice flat 32-bit address space and go back to the old 8086 DOS segments and offsets as a programming paradigm, things are not going to improve. The problem with the old DOS is that segments were used to break the 64k barrier in a flat address space rather than used as segments. With the 386 architecture, segments are no longer limited to 64k, and there is no correlation between segment number and physical address.
On the Linux side, the exploits discovered, exposed and maybe even fixed. On the Microsoft side, the exploits discovered and put into a private cache for a rainy day. Not exposed. Not fixed. Remember the ZDnet crack-this-box thingy. After the very well-done expose of the Linux crack, if I did have a crack on the Microsoft box, there is no way I would have tried to follow him. Besides, there is too much risk of the Microsoft target being behind a well-crafted BSD firewall.
On Intel hardware, all addresses are bounds checked during run-time by the hardware. The problem is that code, data, and stack all point to the same memory with the bounds set to all of memory. The basic problem is using the nice flat 32-bit memory space rather than the messy segment pointers. Since Multics died and Unix survived (Windoze seems even worse), it will be a long time before things get better. There is too much of a horse race mentality. The winner is whoever is faster by a nose.
Actually type safety has everything to do with buffer flows. The problem is that the types available are either unsafe or unchecked. What is the type of a pointer to a 120 character buffer? If the effective type is a pointer to max 64k bytes starting here, then it is unsafe. Strongly typed languages are easier to write programs in that do not have certain kinds of bugs. They are harder to write programs in that are buggy and seem to work OK. Will things get any better? No. There are too many buggy programs that sorta work well enough that will be stopped dead by anything that enforces safety. What I'd love to see is a good free production-quality Algol68 compiler. The 68 stands for the year 1968. Progress? nah.:(
This is from an Intel 80386 Programmer's Reference manual, a bit dated, but should be still valid. There are 4 privilege levels. Does anything other than Multics use more than 2? Code, Stack, and Data exist in completely seperable address spaces. A running process has access to some 8000+ local 32-bit address spaces and some 8000+ global 32-bit address spaces. A selector can specify a buffer to byte granularity. Basically, the problem is that in current systems, CS, SS, and DS all point to the same nice linear 32-bit address space. Away with segmentation. It's a bit more complicated than that, but in general, most code can be read and written, most data can be executable. The problem has been solved many times. I think some of the old Burroughs computers did some neat things. Unfortunately the good ones die because of a 5 or 10% performance lag, or they refuse to run certain bugs without complaint.
Executable code on the stack??? Seems like a very bad idea. Null terminated strings. Nice trick, but miss a \0 or try to handle raw binary, and you have severe problems.
Will anything get solved? Probably not. Any solution will break existing code, or more realistically, discover that the existing code was already broken, only nothin knew or cared about the consequences.
Very true. Even identical brand/model# can vary.The devil is in the details, the exact timings, and these do vary somewhat. As a generality, The BSDs (at least FreeBSD and OpenBSD) seem to have stronger networking abilities than Linux, but the differences seem more in the ability to handle screwy setups than the mainstream. I am working on newbie status, but have been around computers long enough to know what a wiring panel (IBM/604 IBM/650) looks like. The following is anecdotal, but may have some relevance. First exposure was FreeBSD (2.6 I think) hooking up 2 486/33s via serial ports to learn that there was such a thing in TCP/IP as MTU which is 1500 for ethernet and defaults to something like 384 for serial links. (Windoze likes to set a "Do Not Fragment" bit.) The setup was DOS boxes routing Internet explorer and email over some embedded phone lines. Don't ask, we've got fiber now. BSDs eventually died, probably from overflowing/var (I'd never heard of df at that time). I've had RedHat 4.2 (kernel upgraded to 2.2.10) on a 486/50 for a few years, ftp, samba, mostly so I can read man pages. Not really set up for anonymous ftp. Anonymous ftp works, just nothing there. Pair of box-du-jour, one would install RedHat 4.2 but not 5.2; the other would install 5.2 but not 4.2. No idea why. Ftp installs from intranet servers not particularly set up for ftp installs. OpenBSD, smooth as silk, just put in pertinent info where defaults are not what you want. FreeBSD, other than having to remember to set ftp username in options, goes smoothly. RedHat 6.2 requires ftp server to be set up appropriately. From installs on various misbegotten and damaged (power surges) boxen, Linux tends to be a bit more user friendly, at least for a novice. When there are problems, the BSDs tend to be a bit more usefully informative. If either works, it tends to stay working. One word of warning, the BSDs handle disk partitioning differently. For me at least, the partitioning in OpenBSD is very non-intuitive. For any of the BSDs you probably want bash instead of the default sh. With at least 17" monitor, 2meg video, 200MHz PPro, RedHat 6.2 gives a very easy "wow" desktop setup. One good thing about the overloaded GUI in RedHat. On a default RedHat install (RedHat 6.2 Professional, intended as a server (almost as good as OpenBSD, but the box is more impressive)), with a bunch of windows open, and the default random screensaver doing interesting things, telnet in from an NT box, and everything is crisp. Hit the mouse (move is too slow) and the original screen is back before the mouse has come to rest. Ever watch NT recover from a 3d screensaver? Painful. I think my boss is getting the idea than Linux/BSD will work better than Windows 2000. We already have had, and scrapped, Exchange Server, Small Business server, Proxy Server, and SQL Server. If you have a chance, try them all. I think the best choice will be whatever works and feels right. It's almost like choosing a car because you like the color. There's more to it than that, but the relevant stuff is subtle, subliminal, and outside the scope of what can be objectively measured. On topic? I have always avoided sound cards as much as possible. Almost always more trouble than they are worth. This is "mainstream" NT and Win95/98.
A bank has two kinds of assets. Money is kept in the vault, and the flowering plants are kept outside where any passerby could come by at night and abscond with them. It works much better if the bank does not get confused as to which is which.
The source has a built-in bias as to what the programmer thinks it should do. Unless the programmer is extraordinarily gifted, there is a substantial difference between what the code does in fact do and what the programmer thinks it does. The differences can be subtle and fiendish. There is an old debugging trick (works better with assembler) of covering up the comments so as not to be mislead.
I am a lazy sysadmin. I am looking at a report of a new cracking exploit with the associated bugfix. Do I apply the bugfix?
If I do not understand the exploit, probably not. If I understand the exploit but have no easy way to test it, probably not. If I have an easy way to demonstrate the exploit, the odds improve. If I have an easy way to demonstrate the exploit, and I do not want things like that to happen to me, then I will take the effort to apply the bugfix.
Personally I think the script kiddies serve as an early warning system for the bad things to come.
Reasons to secure a box. Imagine being two or three levels upstream of an well-concealed deadly attack and the Feds come investigating.
Ever since whoever got a Pulitzer for blathering about the Hindenberg (apparently caused by a bad choice of paint instead of the hydrogen gas), the media has been trying to go it one better. I think I'm right on this, but flame me if I'm wrong.
Maybe you are preaching to the choir, but it is much like little raindrops attacking big mountains. It's slow, but the relentless pressure does in fact move mountains.
...However, those using Outlook in Exchange Server using the Messaging Application Programming Interface "don't have anything to worry about." Arrgh. Not being vulnerable to one particular exploit is NOT the same as being invulnerable to ALL exploits.
I think you are very right. The problem is not the script-kiddies who do minor damage with well publicized exploits, but ill-intentioned competent individuals who have a private stock of exploits. Accidentally run into some anomalous result of an accidental bug. Use machine-code level debugger to discover what the code actually does (enough difference so that having the source is actually a liability). With its history and habit of applying band-aids over large holes, you know there are some very juicy "undiscovered" exploits.
1. Stand on dry carpet 2. Plug in 9000 volt neon transformer 3. Connect to one side of output. Other side is not connected. 4. Hold flourescent tube up in the air. It will glow.
Strong agreement. Assume a lot of files in the group, scattered in several different directories, folders, or whatever they are called, and now add members or delete members, and just try to remember where all the files are. Should make for some very anomalous results.;) RedHat, mayby other distributions, creates a group with the same name as a new user. To handle group membership, create a user with same name as the group. With some mechanism so that the user can effectively edit her/his one line in/etc/group, root would not have to be constantly bothered added and deleting members. Re NT's ACLs, I was fuming for a few days after I discovered that groups and users cannot have the same names.;)
Figures. The author is trying to find an objective metric for security, and unfortunately for him what is easy to measure is not particularly relevant, and what is relevant is extremely difficult to measure. Without actually knowing much about Debian or Slackware, I would expect either to be more secure than any of RedHat, SuSE, Turbo, Caldera, Mandrake, Storm, because of an emphasis on doing it right rather than having the latest and greatest. Think of new bugs as exploits that require zero effort on the part of the exploiters.;)
It's a different kind of reboot, and a different sequence. Instead of edit config, reboot, edit config, reboot, it is edit config, edit config, test config, and finally reboot to ensure that everything comes up right after the next long power failure, when you have forgotten what you wanted to do. Think bringing up an ethernet card manually with ifconfig and route on a server in a far-off location.
Right on. The OS and standard utilities give a pervasive impression of how good things ought to be. I think Microsoft may have set us back a couple of generations.
What reason would I have to believe that this (or is it two of them now?) is the last one, or the one with my name on it? Somehow I think I'm better off not applying the patches and know that I am not safe.
A C function can return a pointer to a previously existing function. What it cannot do is to _create_ a function and return a reference to it. One critical difference is that a functional language will allow a program to be written top-down.
If I remember correctly, an internal combustion engine is limited by thermodynamics to something like 35% efficiency. Something to do with extracting work due to difference in temperature between the combustion chamber and ambient temperature. Judging from some other comments, the realized efficiency is something like half of that, about 17%. So there is some room for improving efficiency. Fuel cells can be something like 90+% efficient by coaxing electricity from the oxidation process. I think the main problem with fuel cells is getting power from them at a high enough rate. The main reason that alternative fuels don't do very well is that petroleum fuels are incredibly cheap. To match the energy content of $2.00 a gallon gasoline, you need 100 proof vodka at less than 20 cents a fifth.
Slashdot Mirror
Yep. I wonder how insecure NT really is. It has the feel of an accident looking for a place to happen. Of course whoever really knows is not talking. There would have to be an enormous amount of satisfaction from finding and plugging the _last_ security hole in linux. With two exploits in Outlook published in the same week, I feel safer ignoring it and watching /. for the fix for the next one that gets loose in the wild without a prior announcement. Worked for the Love Bug. It took Microsoft three days for a search for I LOVE YOU to show anything on their web site.
>>requires advanced OS'es which have not been developed yet.
You mean like Multics? Or the old Burroughs mainframes?
Arggh.
If the Code Segment is not marked readable, you cannot read the code.
You can't jump into the stack. You can jump to a "far return address" that is stored in the stack. You can jump to an address in the Code Segment which just happens to be coincident with something in the Stack Segment.
With NO CONTEXT SWITCHES, there are 8000+ local code spaces, 8000+ global code spaces, 8000+ local data spaces, 8000+ global data spaces, 8000+ local stack spaces, 8000+ global stack spaces. All these code and data spaces. All independent. All in the same context. But the OS has to handle them. No OS wants to bother. They all effectively point code, data, and stack to the same memory with bounds set to all of memory.
There are four protection levels, but only Multics that I am aware of has ever used more than two levels.
The hardware design of the 80386 is targeted at a Multics-like OS. Current i386 code is using separate code data and stack spaces, with bounds checking on all references to memory. Unfortunately, code, data, and stack point to the same memory with the bounds being all of memory.
Speed. Loading a segment register is comparable to integer multiply, the instruction, not the addressing shortcut.
Unless Operating Systems, Language designers, and programmers are willing to give up the nice flat 32-bit address space and go back to the old 8086 DOS segments and offsets as a programming paradigm, things are not going to improve. The problem with the old DOS is that segments were used to break the 64k barrier in a flat address space rather than used as segments. With the 386 architecture, segments are no longer limited to 64k, and there is no correlation between segment number and physical address.
On the Linux side, the exploits discovered, exposed and maybe even fixed.
On the Microsoft side, the exploits discovered and put into a private cache for a rainy day. Not exposed. Not fixed.
Remember the ZDnet crack-this-box thingy. After the very well-done expose of the Linux crack, if I did have a crack on the Microsoft box, there is no way I would have tried to follow him. Besides, there is too much risk of the Microsoft target being behind a well-crafted BSD firewall.
On Intel hardware, all addresses are bounds checked during run-time by the hardware. The problem is that code, data, and stack all point to the same memory with the bounds set to all of memory. The basic problem is using the nice flat 32-bit memory space rather than the messy segment pointers. Since Multics died and Unix survived (Windoze seems even worse), it will be a long time before things get better. There is too much of a horse race mentality. The winner is whoever is faster by a nose.
Actually type safety has everything to do with buffer flows. The problem is that the types available are either unsafe or unchecked. :(
What is the type of a pointer to a 120 character buffer? If the effective type is a pointer to max 64k bytes starting here, then it is unsafe.
Strongly typed languages are easier to write programs in that do not have certain kinds of bugs. They are harder to write programs in that are buggy and seem to work OK.
Will things get any better? No. There are too many buggy programs that sorta work well enough that will be stopped dead by anything that enforces safety. What I'd love to see is a good free production-quality Algol68 compiler. The 68 stands for the year 1968. Progress? nah.
I'd much rather Debian developers be cats than sheeple. Besides, I like cats.
This is from an Intel 80386 Programmer's Reference manual, a bit dated, but should be still valid.
There are 4 privilege levels. Does anything other than Multics use more than 2?
Code, Stack, and Data exist in completely seperable address spaces.
A running process has access to some 8000+ local 32-bit address spaces and some 8000+ global 32-bit address spaces.
A selector can specify a buffer to byte granularity.
Basically, the problem is that in current systems, CS, SS, and DS all point to the same nice linear 32-bit address space. Away with segmentation. It's a bit more complicated than that, but in general, most code can be read and written, most data can be executable.
The problem has been solved many times. I think some of the old Burroughs computers did some neat things. Unfortunately the good ones die because of a 5 or 10% performance lag, or they refuse to run certain bugs without complaint.
Executable code on the stack??? Seems like a very bad idea.
Null terminated strings. Nice trick, but miss a \0 or try to handle raw binary, and you have severe problems.
Will anything get solved? Probably not. Any solution will break existing code, or more realistically, discover that the existing code was already broken, only nothin knew or cared about the consequences.
Very true. /var (I'd never heard of df at that time).
Even identical brand/model# can vary.The devil is in the details, the exact timings, and these do vary somewhat.
As a generality, The BSDs (at least FreeBSD and OpenBSD) seem to have stronger networking abilities than Linux, but the differences seem more in the ability to handle screwy setups than the mainstream.
I am working on newbie status, but have been around computers long enough to know what a wiring panel (IBM/604 IBM/650) looks like. The following is anecdotal, but may have some relevance.
First exposure was FreeBSD (2.6 I think) hooking up 2 486/33s via serial ports to learn that there was such a thing in TCP/IP as MTU which is 1500 for ethernet and defaults to something like 384 for serial links. (Windoze likes to set a "Do Not Fragment" bit.) The setup was DOS boxes routing Internet explorer and email over some embedded phone lines. Don't ask, we've got fiber now. BSDs eventually died, probably from overflowing
I've had RedHat 4.2 (kernel upgraded to 2.2.10) on a 486/50 for a few years, ftp, samba, mostly so I can read man pages. Not really set up for anonymous ftp. Anonymous ftp works, just nothing there.
Pair of box-du-jour, one would install RedHat 4.2 but not 5.2; the other would install 5.2 but not 4.2. No idea why.
Ftp installs from intranet servers not particularly set up for ftp installs. OpenBSD, smooth as silk, just put in pertinent info where defaults are not what you want. FreeBSD, other than having to remember to set ftp username in options, goes smoothly. RedHat 6.2 requires ftp server to be set up appropriately.
From installs on various misbegotten and damaged (power surges) boxen, Linux tends to be a bit more user friendly, at least for a novice. When there are problems, the BSDs tend to be a bit more usefully informative. If either works, it tends to stay working. One word of warning, the BSDs handle disk partitioning differently. For me at least, the partitioning in OpenBSD is very non-intuitive. For any of the BSDs you probably want bash instead of the default sh.
With at least 17" monitor, 2meg video, 200MHz PPro, RedHat 6.2 gives a very easy "wow" desktop setup. One good thing about the overloaded GUI in RedHat. On a default RedHat install (RedHat 6.2 Professional, intended as a server (almost as good as OpenBSD, but the box is more impressive)), with a bunch of windows open, and the default random screensaver doing interesting things, telnet in from an NT box, and everything is crisp. Hit the mouse (move is too slow) and the original screen is back before the mouse has come to rest. Ever watch NT recover from a 3d screensaver? Painful. I think my boss is getting the idea than Linux/BSD will work better than Windows 2000. We already have had, and scrapped, Exchange Server, Small Business server, Proxy Server, and SQL Server.
If you have a chance, try them all. I think the best choice will be whatever works and feels right. It's almost like choosing a car because you like the color. There's more to it than that, but the relevant stuff is subtle, subliminal, and outside the scope of what can be objectively measured.
On topic? I have always avoided sound cards as much as possible. Almost always more trouble than they are worth. This is "mainstream" NT and Win95/98.
A bank has two kinds of assets. Money is kept in the vault, and the flowering plants are kept outside where any passerby could come by at night and abscond with them.
It works much better if the bank does not get confused as to which is which.
The source has a built-in bias as to what the programmer thinks it should do. Unless the programmer is extraordinarily gifted, there is a substantial difference between what the code does in fact do and what the programmer thinks it does. The differences can be subtle and fiendish.
There is an old debugging trick (works better with assembler) of covering up the comments so as not to be mislead.
I am a lazy sysadmin.
I am looking at a report of a new cracking exploit with the associated bugfix.
Do I apply the bugfix?
If I do not understand the exploit, probably not.
If I understand the exploit but have no easy way to test it, probably not.
If I have an easy way to demonstrate the exploit, the odds improve.
If I have an easy way to demonstrate the exploit, and I do not want things like that to happen to me, then I will take the effort to apply the bugfix.
Personally I think the script kiddies serve as an early warning system for the bad things to come.
Reasons to secure a box. Imagine being two or three levels upstream of an well-concealed deadly attack and the Feds come investigating.
Ever since whoever got a Pulitzer for blathering about the Hindenberg (apparently caused by a bad choice of paint instead of the hydrogen gas), the media has been trying to go it one better. I think I'm right on this, but flame me if I'm wrong.
Maybe you are preaching to the choir, but it is much like little raindrops attacking big mountains. It's slow, but the relentless pressure does in fact move mountains.
...However, those using Outlook in Exchange Server using the Messaging Application Programming Interface "don't have anything to worry about."
Arrgh. Not being vulnerable to one particular exploit is NOT the same as being invulnerable to ALL exploits.
I think you are very right. The problem is not the script-kiddies who do minor damage with well publicized exploits, but ill-intentioned competent individuals who have a private stock of exploits. Accidentally run into some anomalous result of an accidental bug. Use machine-code level debugger to discover what the code actually does (enough difference so that having the source is actually a liability). With its history and habit of applying band-aids over large holes, you know there are some very juicy "undiscovered" exploits.
The beauty of AutoCAD release 14 is that finally AutoCAD can speak with a persistent LISP ;)
setvar lispinit 0 -- and lisp functions and data survive loading a new drawing.
1. Stand on dry carpet
2. Plug in 9000 volt neon transformer
3. Connect to one side of output. Other side is not connected.
4. Hold flourescent tube up in the air. It will glow.
Strong agreement. ;) /etc/group, root would not have to be constantly bothered added and deleting members. Re NT's ACLs, I was fuming for a few days after I discovered that groups and users cannot have the same names. ;)
Assume a lot of files in the group, scattered in several different directories, folders, or whatever they are called, and now add members or delete members, and just try to remember where all the files are. Should make for some very anomalous results.
RedHat, mayby other distributions, creates a group with the same name as a new user. To handle group membership, create a user with same name as the group. With some mechanism so that the user can effectively edit her/his one line in
Figures. ;)
The author is trying to find an objective metric for security, and unfortunately for him what is easy to measure is not particularly relevant, and what is relevant is extremely difficult to measure. Without actually knowing much about Debian or Slackware, I would expect either to be more secure than any of RedHat, SuSE, Turbo, Caldera, Mandrake, Storm, because of an emphasis on doing it right rather than having the latest and greatest.
Think of new bugs as exploits that require zero effort on the part of the exploiters.
It's a different kind of reboot, and a different sequence. Instead of edit config, reboot, edit config, reboot, it is edit config, edit config, test config, and finally reboot to ensure that everything comes up right after the next long power failure, when you have forgotten what you wanted to do. Think bringing up an ethernet card manually with ifconfig and route on a server in a far-off location.
;-)
Right on. The OS and standard utilities give a pervasive impression of how good things ought to be. I think Microsoft may have set us back a couple of generations.
What reason would I have to believe that this (or is it two of them now?) is the last one, or the one with my name on it? Somehow I think I'm better off not applying the patches and know that I am not safe.
>>... also learned everything one needs to know about securing my NT box. ... until ... ;)
Yeah, sure, right. Nothing to worry about.
A C function can return a pointer to a previously existing function. What it cannot do is to _create_ a function and return a reference to it.
One critical difference is that a functional language will allow a program to be written top-down.
If I remember correctly, an internal combustion engine is limited by thermodynamics to something like 35% efficiency. Something to do with extracting work due to difference in temperature between the combustion chamber and ambient temperature. Judging from some other comments, the realized efficiency is something like half of that, about 17%. So there is some room for improving efficiency.
Fuel cells can be something like 90+% efficient by coaxing electricity from the oxidation process. I think the main problem with fuel cells is getting power from them at a high enough rate.
The main reason that alternative fuels don't do very well is that petroleum fuels are incredibly cheap. To match the energy content of $2.00 a gallon gasoline, you need 100 proof vodka at less than 20 cents a fifth.