Please create an account to participate in the Slashdot moderation system


Forgot your password?

Comment Re:Jesus H. Christ (Score 1) 345

"No replacement for displacement" trades meaning for rhyme

No, it doesn't. In the context of engines, "no replacement for displacement" and "no substitute for cubic inches" are equally meaningful. At least to Americans. To everyone else, the latter sacrifices BOTH meaning and rhyme.

And attitude.

Really, that's the big one. When a gearhead says, "There's no replacement for displacement," it conveys exactly the kind of macho attitude that you'd expect from someone who revels in big engines. The statement "there's no substitute for cubic inches" does not. It doesn't just lack rhyme or finesse, it lacks attitude and meaning.

Google says:
"there no substitute for cubic inches" About 7,850 results
"no replacement for displacement" About 266,000 results while I can't say for sure when the latter first entered common use, I'm reasonably certain that it's the more common phrase, by a ratio of about 35 to 1.

Comment Re:Finally! (Score 1) 221

C is an excellent system programming language and nothing else has managed to supersede it. All major operating systems are written in C, including Linux, the BSD/MacOS kernel and the Windows kernel.

Both the XNU kernel (OS X and iOS) and Windows kernel are written, in part, in C++. A subset of C++, in both cases, to be fair, but C++ all the same.

Comment Re:OSX in 2013. (Score 1) 231

Actually, that clarifies that the zram feature did not make it to the Linux kernel until 2014, meaning that OSX had it prior to Linux.

zswap, which is similar to the OS X feature, was merged into the Linux kernel mainline in kernel version 3.11, released on September 2, 2013. OS X 10.9 "Mavericks" was released on October 22, 2013.

But compressed memory isn't new. It's old tech, and quibbling about which of the many implementations was released first is silly as it ignores decades of such products.

Comment Re:OSX in 2013. (Score 5, Informative) 231

That document is several years old now.

Oh, so it's not enabled by default in my distro?

It appears to be enabled currently in both Ubuntu, Fedora, and RHEL and CentOS.

Oh, great, it's experimental.

It was marked experimental in 2013. In the context of a discussion about a feature that hasn't even been introduced in Windows, it's fair to note that Linux developers have been working on such a feature, and made it generally available several years earlier.

Wonderful! If I turn it on, it may suddenly turn itself off when I get a kernel update for 14.04.

It was disabled in Ubuntu while they tried to diagnose instability in a PPC kernel. The feature was not related to the instability.

If you don't like Ubuntu's method of kernel maintenance, by all means, use a different distribution. However, the practices of one company should not be considered a defect in *Linux*.

Saying you have something when it's experimental, not enabled by default, enables and disables with updates, and not easily available to the vast majority of your users is silly.

It would be, perhaps, but you have all of your facts wrong.

Comment Re:Better Title (Score 2) 127

but osx being exploitable if you have console/local access? that's not really news.

I don't know why so many people don't get this.

The bug doesn't require a human at the console. Any code-execution bug can be escalated to root access because of this bug. It is not, by itself, a remote root, but security vulnerabilities can be combined, and a combination of bugs typically rates at the highest threat level of any individual element of the combined attack.

That is, imagine that you have a bug in your browser that causes it to automatically open PDF files in an external viewer. This rates as a minor security threat. You also have a PDF reader that allows code execution, but code executes as the user, with limited rights, so this rates as a moderate security threat. You also have a dynamic linker that allows any process that can call system() to write to protected files. This is a critical security vulnerability.

An attacker can now infect a server that you visit, or maybe convince you to visit a server that they control, and combine those to get root access on your system.

Comment Re:Misleading and Hyperbolic Title/Comparison (Score 1) 130

I hate to repeat myself, but: Any exploit that allows execution of code in a user's own context can be escalated to root access by this exploit.

So.. Your PDF reader has an exploit that allows code execution. Without the dyld bug, the PDF bug only allows code to execute in the user's context. With the dyld bug, the PDF bug can give itself passwordless sudo access, and execute shell commands as root.

Comment Re:You're welcome (Score 1) 130

Apple clearly forgot to sanitize the new DYLD_PRINT_TO_FILE

They also forgot to set the close-on-exec flag for the file they open. If they had done that, then at least only the SUID application would be a target, instead of the SUID application and any child process.

which outputs the string "$(whoami) ALL=(ALL) NOPASSWD:ALL" into fd 3

Actually, $(whoami) will be executed and its output substituted by the shell. The username of the user will replace that string, so root access will be granted by sudo only to the user that runs the exploit, not to all users. This would give root access to all users:

echo 'echo "ALL ALL=(ALL) NOPASSWD:ALL" >&3' | DYLD_PRINT_TO_FILE=/etc/sudoers newgrp; sudo -s

Comment Re: How the hell does this get into live software? (Score 1) 130

I think even Linux was affected at one time.

Yes. The Linux dynamic linker had a list of environment variables that it cleared when executing in a SUID context, for security. A comma was removed from the list, which caused the compiler to concatenate two of the strings. The result was that neither of those two variables were cleared, and so "LD_PRELOAD" could be used to load a replacement shared library into a SUID binary.

Whoever dies with the most toys wins.