All I got from the article is that there is an "unspecified remote code-execution vulnerability". This doesn't necessarily mean a stack overflow. And while a 'stack canary' is a good security measure, it still doesn't protect against a stack overflow that overwrites local variables without touching the return address.
The reason I say this is that they may already be using these security measures. I know any version of Visual Studio that isn't prehistoric turns this feature (/GS) on by default.
I concur totally; I think the freedom to be able to speak up when you have something to add is a beautiful thing. Sure, it also means you have to be careful of all the crackpots and misinformation out there. So what? If you believe everything you read, then there's something wrong with you anyway.
So, given the odds of picking anyone who knows anything about Linux or software development in general out of the population at large, I don't think you want to further limit your odds of success by throwing out all the females...
You're in a room with 2X number of people in it, half are men and half are women (X of them are women and X of them are men). The number of men in the room that can answer your question about Linux is Y. The number of women in the room that can answer your question is some fraction of that - lets just say it's 0.5Y to keep things simple. If you choose a man randomly, your chance of picking one who can answer your question is Y/X. If you choose a person randomly, your chance is (Y + 0.5Y)/(X + X) or 1.5Y/2X.
1.5Y/2X is less than Y/X for all integers Y where 1 Y = X. You increase your odds by throwing out all the females, as long as we can accept the assumption that women in general are less likely to know things about Linux than men.
"The purposeful hiding of data by the subject of an investigation is in itself important evidence and there are many scenarios where intentional data cloaking provides incriminating evidence, even if the perpetrator is successful in cloaking the data itself."
Yes of course because if you're hiding something - anything, even something unrelated to the crime that you're being tried for - then that suggests that you're guilty.
If you wear pants on a hot day then you're doing it to hide something. Yet I don't think anyone would suggest that your decision to wear pants should be used as evidence to convict you of a crime.
> People that have a decent expert opinion with computers typically don't even use AV software..
I'm a programmer. I haven't had any sort of AV software installed on my computer for at least 5 years, and in that time I have had no virus problems whatsoever. I suppose someone could argue that I might have a virus and I just don't know it, but if that's the case then I'd probably prefer having the virus to having AV software that cripples the system and forces me to buy new hardware every 2 years.
With no research, it's their subconscious that ends up voting. What does the subconscious rely on? Clever, well-timed, or memorable TV spots, signs, telephone calls, whatever.
I agree.
It's also impossible to get any useful information from any of these ads. Since most big issues are a double-edged sword, politicians are afraid to say that they stand on side X of an issue because they don't want to alienate all the people who stand on side Y regarding that issue. The ads either turn into mudslinging contests or end up trying to sell the politician's name like it's a brand name. Telling me that a politician has 'experience' and 'integrity' in an advertisement says nothing, and only serves to help me remember the name so I'll be more familiar with it and more likely to vote for that person when I go to the polls.
--PPC has no specific nop instruction. I was getting it confused with the syscall instruction. "nop sleds" may still be written for PPC with sequences of instructions such as 'or $t4, $t4, $t4', so the point that nop sleds with no nulls in them can be constructed easily still holds.
--Point about the processor ignoring the nulls in instructions is true for syscall. Probably a simplification to cut costs. Once again, I got it confused with 'nop' for some reason.
...this doesn't change any of my major points, though.
The Harvard architecture that the PowerPC uses is inherently more secure than x86. A remote exploit on running code has a very low chance of working on the PPC, but nearly a 100% chance on the x86 (which is why all these IE exploits work all the time).
The PPC architecture isn't very different, from a security standpoint, than the x86. Both store return addresses on the stack where they can be overwritten to redirect execution to wherever the attacker desires. PPC stores the most recent return address in a register, but all the addresses before the most recent go on the stack as in the x86. This doesn't change things much for an attacker.
How is anything more or less likely either way? Guessing the stack address to jump to creates the same problems with either architecture, and both x86 and PPC allow the construction of 'nop' sleds which do not contain null bytes* to make guessing the address easier. I can't think of any other place where probability plays much of a role.
*The PPC nop instruction as written by a compiler contains null bytes, but the three bytes that are null are actually ignored by the processor. This means that the nop instruction can be written without null bytes in it, in a way that the processor will accept.
Then again, Apple has taken massive steps on the x86 side to prevent these kinds of attacks. Such as enforcing the NX/XD bit and enforcing a non-executable stack.
The W^X bit changes the playing field, but does not solve the problem. The problem is that execution can be redirected by rewriting return addresses (which are still data, not executable). Sometimes, code is written on the stack and the return address is overwritten to jump to the code on the stack. W^X prevents this particular method, but there are other ways to do it. Performing returns into libc is one well-known way. I know of another which I think is easier.
The differences in boot times of your systems seem irrelevant. First of all, you aren't comparing custom built FreeBSD to prebuilt FreeBSD, you're comparing it to Windows 2000. The two operating systems are so different it's hard to come to any meaningful conclusion regarding the advantages of building from source by comparing them.
Most people would agree that there is a large difference in bootup time between a GENERIC kernel and a custom built one, but bootup is a special case. The GENERIC kernel is built for compatibility, so there are all sorts of drivers built into it that many people don't use. They're there so people can boot the system and have it 'just work'. At boot time, the kernel has to probe everything and figure out what drivers are best suited for each piece of hardware in the system. If the kernel has a larger pool of drivers to choose from, this process takes longer (as you would probably expect). When a FreeBSD user custom-builds a kernel, he usually takes out all the drivers for hardware he doesn't have or doesn't want support for. This makes the pool of available drivers smaller and hardware detection at boot time becomes faster.
But how quickly a system boots says nothing about how well it performs once it is up and running. While speed at bootup may be important to some people, such as laptop users, what everyone really cares about is the performance advantages of custom-built applications (or a custom-built world/kernel) once the system is started. While I have never done thorough performance benchmarks to compare custom-built applications with pre-built applications, I would expect the performance advantages to be nil.
The overwhelming majority of user applications perform calculations for no more than 5 milliseconds before they give up the CPU to wait for I/O anyway, and a recompile isn't going to speed up your hard disks, your PCI bus, or the speed at which you can press keys on your keyboard. What a desktop user should care about more than speed is response time, but this is a property of the OS that is in most cases completely independent of the application.
I'm not really sure whether I'd expect a measurable difference in performance between a custom built kernel and a prebuilt one. But if you watch your FreeBSD kernel build, you'll notice compiler flags like --nommx, --no3dnow, --nosse and --nosse2. This means that many of the features exclusive to newer processors are not being used by the kernel anyway (this isn't a bad thing - the kernel simply can't do anything useful with them).
As always, there are some exceptions to what I've said here. For example, a special-purpose scientific application which spends a lot of time on the CPU and very little time doing I/O would certainly benefit greatly from a custom build optimized for your processor. A compute-intensive graphics application or a big first-person shooter game would probably benefit as well.
Slashdot Mirror
All I got from the article is that there is an "unspecified remote code-execution vulnerability". This doesn't necessarily mean a stack overflow. And while a 'stack canary' is a good security measure, it still doesn't protect against a stack overflow that overwrites local variables without touching the return address.
The reason I say this is that they may already be using these security measures. I know any version of Visual Studio that isn't prehistoric turns this feature (/GS) on by default.
The Canadian government is secretly negotiating...
Yes they're secretly negotiating. Nobody knows about it yet. Shhh!!!
I concur totally; I think the freedom to be able to speak up when you have something to add is a beautiful thing. Sure, it also means you have to be careful of all the crackpots and misinformation out there. So what? If you believe everything you read, then there's something wrong with you anyway.
You're in a room with 2X number of people in it, half are men and half are women (X of them are women and X of them are men). The number of men in the room that can answer your question about Linux is Y. The number of women in the room that can answer your question is some fraction of that - lets just say it's 0.5Y to keep things simple. If you choose a man randomly, your chance of picking one who can answer your question is Y/X. If you choose a person randomly, your chance is (Y + 0.5Y)/(X + X) or 1.5Y/2X.
1.5Y/2X is less than Y/X for all integers Y where 1 Y = X. You increase your odds by throwing out all the females, as long as we can accept the assumption that women in general are less likely to know things about Linux than men.
"The purposeful hiding of data by the subject of an investigation is in itself important evidence and there are many scenarios where intentional data cloaking provides incriminating evidence, even if the perpetrator is successful in cloaking the data itself."
Yes of course because if you're hiding something - anything, even something unrelated to the crime that you're being tried for - then that suggests that you're guilty.
If you wear pants on a hot day then you're doing it to hide something. Yet I don't think anyone would suggest that your decision to wear pants should be used as evidence to convict you of a crime.
> AV should seriously die a horrible death...
Definitely.
> People that have a decent expert opinion with computers typically don't even use AV software..
I'm a programmer. I haven't had any sort of AV software installed on my computer for at least 5 years, and in that time I have had no virus problems whatsoever. I suppose someone could argue that I might have a virus and I just don't know it, but if that's the case then I'd probably prefer having the virus to having AV software that cripples the system and forces me to buy new hardware every 2 years.
With no research, it's their subconscious that ends up voting. What does the subconscious rely on? Clever, well-timed, or memorable TV spots, signs, telephone calls, whatever. I agree. It's also impossible to get any useful information from any of these ads. Since most big issues are a double-edged sword, politicians are afraid to say that they stand on side X of an issue because they don't want to alienate all the people who stand on side Y regarding that issue. The ads either turn into mudslinging contests or end up trying to sell the politician's name like it's a brand name. Telling me that a politician has 'experience' and 'integrity' in an advertisement says nothing, and only serves to help me remember the name so I'll be more familiar with it and more likely to vote for that person when I go to the polls.
A few technical errors (sorry):
...this doesn't change any of my major points, though.
--PPC has no specific nop instruction. I was getting it confused with the syscall instruction. "nop sleds" may still be written for PPC with sequences of instructions such as 'or $t4, $t4, $t4', so the point that nop sleds with no nulls in them can be constructed easily still holds.
--Point about the processor ignoring the nulls in instructions is true for syscall. Probably a simplification to cut costs. Once again, I got it confused with 'nop' for some reason.
The Harvard architecture that the PowerPC uses is inherently more secure than x86. A remote exploit on running code has a very low chance of working on the PPC, but nearly a 100% chance on the x86 (which is why all these IE exploits work all the time).
The PPC architecture isn't very different, from a security standpoint, than the x86. Both store return addresses on the stack where they can be overwritten to redirect execution to wherever the attacker desires. PPC stores the most recent return address in a register, but all the addresses before the most recent go on the stack as in the x86. This doesn't change things much for an attacker.
How is anything more or less likely either way? Guessing the stack address to jump to creates the same problems with either architecture, and both x86 and PPC allow the construction of 'nop' sleds which do not contain null bytes* to make guessing the address easier. I can't think of any other place where probability plays much of a role.
*The PPC nop instruction as written by a compiler contains null bytes, but the three bytes that are null are actually ignored by the processor. This means that the nop instruction can be written without null bytes in it, in a way that the processor will accept.
Then again, Apple has taken massive steps on the x86 side to prevent these kinds of attacks. Such as enforcing the NX/XD bit and enforcing a non-executable stack.
The W^X bit changes the playing field, but does not solve the problem. The problem is that execution can be redirected by rewriting return addresses (which are still data, not executable). Sometimes, code is written on the stack and the return address is overwritten to jump to the code on the stack. W^X prevents this particular method, but there are other ways to do it. Performing returns into libc is one well-known way. I know of another which I think is easier.
The differences in boot times of your systems seem irrelevant. First of all, you aren't comparing custom built FreeBSD to prebuilt FreeBSD, you're comparing it to Windows 2000. The two operating systems are so different it's hard to come to any meaningful conclusion regarding the advantages of building from source by comparing them.
Most people would agree that there is a large difference in bootup time between a GENERIC kernel and a custom built one, but bootup is a special case. The GENERIC kernel is built for compatibility, so there are all sorts of drivers built into it that many people don't use. They're there so people can boot the system and have it 'just work'. At boot time, the kernel has to probe everything and figure out what drivers are best suited for each piece of hardware in the system. If the kernel has a larger pool of drivers to choose from, this process takes longer (as you would probably expect). When a FreeBSD user custom-builds a kernel, he usually takes out all the drivers for hardware he doesn't have or doesn't want support for. This makes the pool of available drivers smaller and hardware detection at boot time becomes faster.
But how quickly a system boots says nothing about how well it performs once it is up and running. While speed at bootup may be important to some people, such as laptop users, what everyone really cares about is the performance advantages of custom-built applications (or a custom-built world/kernel) once the system is started. While I have never done thorough performance benchmarks to compare custom-built applications with pre-built applications, I would expect the performance advantages to be nil.
The overwhelming majority of user applications perform calculations for no more than 5 milliseconds before they give up the CPU to wait for I/O anyway, and a recompile isn't going to speed up your hard disks, your PCI bus, or the speed at which you can press keys on your keyboard. What a desktop user should care about more than speed is response time, but this is a property of the OS that is in most cases completely independent of the application.
I'm not really sure whether I'd expect a measurable difference in performance between a custom built kernel and a prebuilt one. But if you watch your FreeBSD kernel build, you'll notice compiler flags like --nommx, --no3dnow, --nosse and --nosse2. This means that many of the features exclusive to newer processors are not being used by the kernel anyway (this isn't a bad thing - the kernel simply can't do anything useful with them).
As always, there are some exceptions to what I've said here. For example, a special-purpose scientific application which spends a lot of time on the CPU and very little time doing I/O would certainly benefit greatly from a custom build optimized for your processor. A compute-intensive graphics application or a big first-person shooter game would probably benefit as well.