Slashdot Mirror


Windows DLL Vulnerability Exploit In the Wild

WrongSizeGlass writes "Exploit code for the DLL loading issue that reportedly affects hundreds of Windows applications made its appearance on Monday. HD Moore, the creator of the Metasploit open-source hacking toolkit, released the exploit code along with an auditing tool that records which applications are vulnerable. 'Once it makes it into Metasploit, it doesn't take much more to execute an attack,' said Andrew Storms, director of security operations for nCircle Security. 'The hard part has already been done for [hackers].'"

178 comments

  1. Application developers fault by odies · · Score: 2, Informative

    This is actually faulty programming in applications, not Windows. Kind of like buffer overflows. It's what happens when you don't know what you're doing nor are you following secure coding standards.

    Because application developers, not Windows, are to blame, Microsoft can't patch the operating system without crippling an unknown number of programs that run on the platform.

    There are no reports of any Microsoft or default Windows applications containing the bug, so unless you have a specific third party app you're not vulnerable. Also, there is already a tool available from Microsoft you can use to block it from all applications, but some of the apps might obviously break.

    To protect from stupid developers you would probably need something like selinux for Windows, but considering how much pain in the ass it is on Linux too, it wouldn't really work for all the casual people. However, moving applications from languages like C/C++ to languages like C# can help just like with buffer overflows. At least it provides extra layer of security against clueless programmers.

    1. Re:Application developers fault by g0bshiTe · · Score: 1, Interesting

      Many Windows applications don't call code libraries -- dubbed "dynamic-link library," or "DLL" -- using the full pathname, but instead use only the filename, giving hackers wiggle room. Criminals can exploit that by tricking the application into loading a malicious file with the same name as the required DLL. The result: Hackers can hijack the PC and plant malware on the machine.

      This is far from a fence post bug, or a buffer overflow. This is more like either DLL injection, or like the paragraph alludes to replacing a DLL.
      A simple fix would be for a programmer to have their app at initialization checksum any dll it uses.

      --
      I am Bennett Haselton! I am Bennett Haselton!
    2. Re:Application developers fault by UnknowingFool · · Score: 2, Interesting

      How much fault is really debatable. Yes if an application is coded in a such a way that the exploit exists that's partly on the fault of the programmer; however, why should that translate into an exploit on the OS? Also from what it appears, many applications have this problem including some from MS so it does not appear some obscure programming quirk.

      According to reports that first appeared last week, developers, including Microsoft's, have misused a crucial function of Windows, leaving a large number of Windows programs vulnerable to attack because of the way they load components.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    3. Re:Application developers fault by Zocalo · · Score: 5, Insightful

      A simple fix would be for a programmer to have their app at initialization checksum any dll it uses.

      Bad idea. That would likely create more problems than it solves and bring back the worst of DLL hell, especially for frequently updated and used DLLs and also given how badly certain vendor's individual development teams seem to communicate with each other. Say App_A installs v1.0.1 of a DLL in a shared location, then later App_B then comes along and updates this to v1.0.2 - congratulations; you just broke App_A. OK, there's a fix for that, but only if you can call the awful kludge that is WinSxS a "fix".

      --
      UNIX? They're not even circumcised! Savages!
    4. Re:Application developers fault by clone53421 · · Score: 1

      A simple fix would be for a programmer to keep data separate from executable code.

      FTFY.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    5. Re:Application developers fault by pelrun · · Score: 5, Insightful

      Yeah, and what happens when that DLL gets updated due to a different vulnerability, but the app doesn't? You either get a broken app or one using an insecure library *anyway*.

    6. Re:Application developers fault by Anonymous Coward · · Score: 1, Insightful

      Nice reasoning there. Take a seat next to the tea party morons and the birthers.

      This exploit compromises the application and needs elevation of privilage to root the OS. If your application runs as an administrator or system, you can be toast. Else only your user account can be compromised.

      It is common practice for shitty programs like ITunes on windows to run a service as the system and do other crap they have no business doing. More surface area + unnecessary elevation of privilege = hacker poodu.

    7. Re:Application developers fault by dbIII · · Score: 2, Interesting

      To protect from stupid developers you would probably need something like selinux for Windows

      Considering the failure of antivirus to protect the first victims of any new virus it looks like that may have to be the way to keep the platform viable. A list of what is allowed provides far better protection than an ever changing list of what is not allowed.

    8. Re:Application developers fault by MojoRilla · · Score: 5, Insightful

      Microsoft created a liberal dynamic library search path that allows (or even encourages) applications to not fully specify DLL locations. Now, after the fact, they publish this security statement saying not to use the dynamic library searching they documented previously. It is of course Microsoft's fault. They didn't consider security at all when loading DLLs, and now they are blaming applications that implemented the documented specification.

      The bottom line is that Windows was never designed to be secure, it was designed to have the most functionality, and trying to patch every hole now is almost impossible. Generally, when code reaches this level of complexity and brittleness, it is often the best course to start all over.

    9. Re:Application developers fault by ILuvSP · · Score: 1

      Exactly! Saying that this is the developer's fault is a bit of a cop-out for Microsoft.

    10. Re:Application developers fault by mdwh2 · · Score: 5, Interesting

      I agree - it's unclear to me what the "fault" of the developer is here, and which applications are at fault. I thought that loading a DLL by name without a specific path was standard practice? And how does it work with linking - in my experience, all applications I've written and used can either use a DLL in the standard path, or be overridden by a local DLL, so surely that's standard practice too? And wouldn't this affect almost every Windows program that uses DLL?

      But then, I'm not sure that this is a bad system anyway. Well, if it's possible to include a DLL loaded off a web page as being the standard path, that seems a gaping hole. However, if this flaw requires an attacker to already install a dodgy DLL in the user's path on their system, surely that would already be the security flaw? I mean, it's a bit like saying "It's a flaw that people can run exes by double clicking, there could be malicious code" - the flaw isn't in running exes, the flaw is how they got there in the first place.

      What is the proposed fix for applications that link to DLLs? And how do other operating systems work - again, I thought that having a path system allowing multiple possible locations for shared libraries wasn't uncommon?

    11. Re:Application developers fault by Anonymous Coward · · Score: 0

      ... shitty programs like ITunes on windows ...

      Its funny, out of the over 40 programs known to be affected, you call out by name the one that is known to have been patched four months ago.

    12. Re:Application developers fault by Anonymous Coward · · Score: 1, Interesting

      Microsoft can try to blame application developers for this, but it is definitely a Windows flaw. Linux and other Unix-like systems are quite secure without requiring developers to specify full paths to the locations of shared libraries. DLL's are no different in this regard. The problem is that, rather than using a separate variable such as LD_LIBRARY_PATH to specify the search path for shared libraries, Windows has always used the same search mechanism that it uses for executables: the contents of PATH and the working directory. It is the implicit inclusion of the working directory that is the problem. But they can't change it without breaking many (almost all?) Windows applications.

    13. Re:Application developers fault by wjousts · · Score: 1

      Doesn't change the fact that it runs as a service for no sensible reason at all.

    14. Re:Application developers fault by Anonymous Coward · · Score: 0

      More than likely he didn't even look to see if ITunes was affected. He called ITunes out for its service infestation policies, not for any faults in the way it loads DLLs.

    15. Re:Application developers fault by denis-The-menace · · Score: 1

      Or you place v1.0.1 of the DLL in the same folder as App_A.exe. App_A will find v1.0.1 of the DLL before going to the shared location *IF* it's written properly. In "MSI packaging Land" this is called "Application Isolation".

      Application Developers are rarely good packagers.

      --
      Obama's legacy: (N)othing (S)ecure (A)nywhere and (T)error (S)imulation (A)dministration
    16. Re:Application developers fault by mcgrew · · Score: 1

      Generally, when code reaches this level of complexity and brittleness, it is often the best course to start all over.

      Or in the immortal words of Montgomery Scott (Star Trek III), "The more you overengineer the plumbing, the easier it is to stop up the drain."

    17. Re:Application developers fault by 0ld_d0g · · Score: 1

      Its shitty because it installs itself as a service (i.e. admin privs) to do some crap it doesn't need to. (according to the OP).

    18. Re:Application developers fault by UnknowingFool · · Score: 1

      I think the reason iTunes runs as a service has to do with automatic syncing. When you plug in your iPhone/iPod/iPad, if you have the service running, iTunes knows to load and then automatic sync. Otherwise you'd have to load iTunes and sync. If that is not your wishes, just turn it off.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    19. Re:Application developers fault by arth1 · · Score: 2, Insightful

      A simple fix would be for a programmer to have their app at initialization checksum any dll it uses.

      That would defeat much of the purpose of using DLLs.
      Not to mention what would happen when Microsoft updates a DLL, or the user runs a rebase.

      To top it off, it's more complex than the real fix too.

    20. Re:Application developers fault by Anonymous Coward · · Score: 1, Insightful

      That doesn't work if the DLL is already loaded on behalf of the other application. You'll get that version, too.

    21. Re:Application developers fault by CKW · · Score: 1

      > The bottom line is that Windows was never designed to be secure

      Oooh, that makes me wonder. Can Linux/Solaris/Unix be attacked *simply* using the PATH environment variable? Forget limiting the attack to shared objects, anything that is loaded or exec'd by any other binary/scripts.

      The complicated thing is many applications build their own PATHs, and you're looking for a directory on that path that is writable to whatever user you are, one that you can put a file that doesn't yet appear that high up on the PATH.

      Which suddenly makes it brilliantly clear that perhaps this isn't an OS problem. Not unless you're going to ALSO blame all the Unix/Linux authors 10-40 years ago for "(not) consider(ing) security at all when (using PATHs)", and for somehow magically making sure applications and installers don't accidentially leave directories writable by other users.

    22. Re:Application developers fault by John+Betonschaar · · Score: 3, Insightful

      Or you place v1.0.1 of the DLL in the same folder as App_A.exe. App_A will find v1.0.1 of the DLL before going to the shared location *IF* it's written properly

      What's the point of having shared libraries if only the application itself can load them, and can only load single, checksummed version of it?

      In "MSI packaging Land" this is called "Application Isolation".

      In the rest of the world we call it 'static linking' :-P

    23. Re:Application developers fault by CKW · · Score: 1

      I wonder how long it would take with dtrace/truss/strace/etc to build a similar tool on Unix/Linux.

      (( Sorry for the quick re-reply (Slashdot, isn't it time for an edit button?) ))

    24. Re:Application developers fault by Anonymous Coward · · Score: 0

      Yeah cause no other Windows syncing tool clutters my taskbar and services.

    25. Re:Application developers fault by Ralish · · Score: 1

      OK, there's a fix for that, but only if you can call the awful kludge that is WinSxS a "fix".

      I always thought that WinSxS was quite an elegant fix to a difficult problem. Put it this way, I still have nightmares about DLL Hell from the bad old days, but have yet to encounter a problem due to WinSxS. The closest I've come is one or two applications making assumptions about dependencies (i.e. not bundling the required installers and not failing gracefully). Have you had issues with WinSxS?

    26. Re:Application developers fault by g0bshiTe · · Score: 1

      I never even considered updated DLL's.

      --
      I am Bennett Haselton! I am Bennett Haselton!
    27. Re:Application developers fault by Zocalo · · Score: 1

      That's why I specified "in a shared location". :)

      I don't actually think there is an easy, one-size-fits-all solution to this problem without a radical shakeup of how Windows handles DLLs. If you insist on applications each installing their own versions of each DLL then you end up with a potential nightmare when there is a flaw found in some versions of a given DLL like with atl.dll a while back. At least you'd know which apps are vulnerable, but that's not going to be much help when one of those is essential to your business and the app breaks if you update the DLL manually.

      --
      UNIX? They're not even circumcised! Savages!
    28. Re:Application developers fault by Anne+Honime · · Score: 1

      You'd need to already own the computer to pull something like that, which pretty much defeats the purpose. But, yes, it's been used in the past, along with other techniques. The intrinsic problem here is not to have a search path for execs and libs, but to provide hardcoded at system level a default path with $PWD included, instead of a path exclusively containing system directories under admin control.

    29. Re:Application developers fault by Ralish · · Score: 1

      Microsoft created a liberal dynamic library search path that allows (or even encourages) applications to not fully specify DLL locations. Now, after the fact, they publish this security statement saying not to use the dynamic library searching they documented previously.

      So basically, your suggestion is to design an OS that ensures that it is secure by taking away API calls that could be misused in a way that compromises security? By your own admission, it is a documented specification, and it is behaving exactly as it is intended to do so. It isn't a "bug" in the API, it's misuse by various developers. However, Microsoft is at fault for how developers (its own or 3rd-party) misuse an API call that is fully documented and behaving exactly as intended? This makes absolute, perfect sense.

      It is of course Microsoft's fault. They didn't consider security at all when loading DLLs, and now they are blaming applications that implemented the documented specification.

      Yes, they are blaming applications that have incorrectly used the documented specification. And, they have provided the capability to control remote loading of DLLs through a patch that can be targetted at individual applications or the entire OS. What more can reasonably be done?

      The bottom line is that Windows was never designed to be secure, it was designed to have the most functionality, and trying to patch every hole now is almost impossible. Generally, when code reaches this level of complexity and brittleness, it is often the best course to start all over.

      And this is factually wrong. Windows NT (as opposed to Windows) was designed from Day 1 to be secure. You can argue whether they succeeded in developing a secure OS, and that might be a far more interesting debate, but to argue that it was never designed to be secure is incorrect. This is a fact of historical record. I'd argue that earlier versions of Windows NT were significantly flawed from a security perspective while modern versions (Vista and newer) are significantly improved, but that's another debate.

      Essentially, your entire argument is that it is Microsoft's fault for providing a documented API that can be misused. I'll grant the defaults could have been chosen better, but competent programmers need to be aware of these issues. I'm mildly surprised it's getting the coverage it is, as this isn't some brand new attack; this issue has been known about for some time and not gotten a lot of coverage because it simply isn't that big a deal and is not a flaw in the underlying OS. For example, this blog post from early 2008 covers the issue (and was linked in some more recent blog posts): DLL Preloading Attacks

    30. Re:Application developers fault by NiteShaed · · Score: 4, Informative

      There are no reports of any Microsoft or default Windows applications containing the bug, so unless you have a specific third party app you're not vulnerable.

      Ummmmmm; "According to Moore, at least one Microsoft executable -- "explorer.exe," the Windows shell -- includes the flaw."
      I'm pretty sure your Windows machine has explorer.exe loaded by default.

      --
      Some bring out the best in others, some the worst. Some bring out far more.
    31. Re:Application developers fault by 0123456 · · Score: 1

      I always thought that WinSxS was quite an elegant fix to a difficult problem.

      Weird, I always thought it was a horrible kludge.

      Put it this way, I still have nightmares about DLL Hell from the bad old days, but have yet to encounter a problem due to WinSxS.

      Either you're lucky or I'm unlucky, because my old XP PC has a serious case of 'SxS Hell' that I've been totally unable to fix. It's a long time since I've booted it, but I remember spending hours poking around in the SxS directories trying to figure out what the hell Windows had screwed up there to prevent some applications from running. It also refuses to install the service pack for the .Net Framework, apparently for the same reason.

      I'm so glad I run Linux for anything other than Windows-only games and video editing these days.

    32. Re:Application developers fault by master_p · · Score: 1

      And all this trouble because Microsoft denied doing the sane thing, i.e. name its DLLs with a version number (as well as the DLL name).

    33. Re:Application developers fault by master_p · · Score: 1

      There is a way out for Microsoft: they can "virtualize" the O/S so as that apps think it's like Windows 95, where they can own all files, but in reality the apps would only do damage to their own version of the files.

    34. Re:Application developers fault by 0123456 · · Score: 1

      A list of what is allowed provides far better protection than an ever changing list of what is not allowed.

      The problem is that vast numbers of Windows programs rely on being able to do things that shouldn't be allowed, and people only buy Windows because it will run all their old Windows programs. So Microsoft are screwed either way.

      Maybe it could be done in 20 years when most people have replaced most software with new versions, or by virtualising all old applications, but it would not be an easy job.

    35. Re:Application developers fault by ThePhilips · · Score: 1

      Because application developers, not Windows, are to blame

      Because clean design of many Windows APIs inspires secure coding practices.

      And MS has totally nothing to do with the fact that some of the APIs are so developer-friendly.

      [/sarcasm]

      --
      All hope abandon ye who enter here.
    36. Re:Application developers fault by interval1066 · · Score: 1

      What do you expect from an OS that has a default color scheme that's very much like the livery of a clown car?

      --
      Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
    37. Re:Application developers fault by xmorg · · Score: 1

      How is this not flamebait?!?! we obviously have a windows fanboy drooling over C#... IE yet another oop language that does garbage collection. That is so 90's bub.

    38. Re:Application developers fault by Anonymous Coward · · Score: 0

      Yeah cause no other Windows syncing tool clutters my taskbar and services

      I don't get your point... it appears that the logic you're attempting to employ is either, because there are OTHER shitty programs out there, iTunes itself isn't shitty, OR it's okay for iTunes to be shitty because there's other shit out there too...

      I don't see how either one discredits or invalidates the original assertion; i.e. iTunes is shitty...

      -AC

    39. Re:Application developers fault by Anonymous Coward · · Score: 0

      You can always sign the assemblies.

    40. Re:Application developers fault by hesaigo999ca · · Score: 1

      i heard even the windows kernel was affected by this, maybe i guess the stupid developers are all at microsoft then?

    41. Re:Application developers fault by Anonymous Coward · · Score: 0

      Not on their system. In the attack scenario the user's current directory, by whatever means, is a foreign system. Maybe it's a PC on the local network, maybe it's a Webdav share on some server in another country.

      They run a perfectly mundane program, which they installed, say, Firefox (NB I do not know if Firefox is affected) and it looks for some DLL, let's say MOZFOO.DLL. Normally it would get the MOZFOO.DLL installed with Firefox. But today there is another MOZFOO.DLL in the Webdav share. So it loads that one.

      Unlike the real MOZFOO.DLL, this one is malware. Whoops, they are now owned.

    42. Re:Application developers fault by Medievalist · · Score: 1

      Many Windows applications don't call code libraries -- dubbed "dynamic-link library," or "DLL" -- using the full pathname, but instead use only the filename, giving hackers wiggle room. Criminals can exploit that by tricking the application into loading a malicious file with the same name as the required DLL. The result: Hackers can hijack the PC and plant malware on the machine.

      Another Result: you can load applications onto network shares and you won't have to load .DLLs on every single machine. This "feature" is extensively used in large corporate and academic networks.

      Another Result: you can run applications with mutually incompatible .DLLs of the same name. Usually not simultaneously, though. A hack that is also extensively used in large corporations.

      Another Result: you can move applications from one folder to another without having to edit the application configuration to include the new path names of .DLLs. Very convenient to end users.

      The vulnerability is ancient and well known, and results from Windows lack of delineation between user space and system space. Apps load shareable objects into the windows system directory by design, which is frankly insane and was known to be insane at least a decade before Microsoft existed as a company.

      Although some windows applications exist that are well behaved and live entirely in a single folder (no registry nonsense, no shareable objects loaded into system space, reasonable permissions on individual components, etc.) very few consumers understand what a good application actually is - the magazine reviews don't help, either, since they tend to concentrate on eye candy and ease of installation, which are among the least important features of most programs.

    43. Re:Application developers fault by geminidomino · · Score: 1

      Or in the immortal words of Montgomery Scott (Star Trek III), "The more you overengineer the plumbing, the easier it is to stop up the drain."

      When he's in(or talking) engineering, he's "Scotty," you heathen.

    44. Re:Application developers fault by wjousts · · Score: 1

      Don't know what it's like these days, but the last time I played with it, it was next to impossible to turn it off. Every time you started iTunes it would reset the service to start every time you start the computer. And I don't have an iPhone/iPod/iPad so there is no reason (other than Apple's arrogance) for the thing to be installed (without asking) in the first place.

    45. Re:Application developers fault by Anonymous Coward · · Score: 0

      further down the specifics of a seperate LD_LIBRARY_PATH are discussed in unix as opposed to windows behaviour of using the current path. these lessons were all learnt back before dos existed. unix doesnt include the current directory in the path by default. this doesnt immediately seem relevant when you are using a gui but code calls other code.

    46. Re:Application developers fault by adisakp · · Score: 1

      Also for what it's worth, the whole idea of a DLL is that it can be updated independently from an app and other DLL's. Keeping a DLL checksum in the app to bind to only a specific instance of that DLL defeats the purpose. At that point, you might as well be just statically link the code to your app.

    47. Re:Application developers fault by Kotten · · Score: 1

      This sounds like .NET as that is the road taken there.

      And yes, I agree with you as I did have the same thoughts when I participated in an introduction course of .NET programming.

      --
      Note to self: Make a sig
    48. Re:Application developers fault by shutdown+-p+now · · Score: 1

      You can absolutely name your own DLLs with a version number, no-one is going to stop you.

    49. Re:Application developers fault by Anonymous Coward · · Score: 0

      However, moving applications from languages like C/C++ to languages like C# can help just like with buffer overflows. At least it provides extra layer of security against clueless programmers.

      Just moving to C# wouldn't prevent this particular problem. Managed memory can deal with memory issues, but memory issues aren't what the problem is here.

      Even with C#, secure coding practices still need to be followed and don't come pre-wrapped into .NET. There are no shortcuts to secure practices out there.

      http://msdn.microsoft.com/en-us/library/ms165101.aspx

    50. Re:Application developers fault by corerunner · · Score: 1

      Other than it growing to over 20 GB, nope, no problems at all.

      --
      "Don't hate the media, become the media." -Jello Biafra
    51. Re:Application developers fault by shutdown+-p+now · · Score: 1

      That's actually by and large what Vista and 7 do when an application without a manifest that declares Vista+ support tries to write into some known system folder that's not writable (e.g. its own install folder under "Program Files"). It silently creates a copy (if file already exists globally) to a user-local, app-specific folder, and then redirects all file operations to that copy.

    52. Re:Application developers fault by postmortem · · Score: 1

      It does not affect every application that uses DLL. It affects only ones that load DLLs dynamically after application is running, using LoadLibrary call. This is different than having a DLL as requisite to load the executable.

    53. Re:Application developers fault by RightSaidFred99 · · Score: 1

      Nonsense. .NET uses signing, you can update the DLL all you'd like if you use the appropriate versioning semantics and sign with the same key.

    54. Re:Application developers fault by Anonymous Coward · · Score: 0

      But how do you write mozfoo.dll to their disk? And if you could, why didn't you just overwrite the original DLL? Do you gain any privilege escalation from writing the file to the current dir you could not get otherwise?

    55. Re:Application developers fault by RightSaidFred99 · · Score: 1

      Bull. He scanned it, found the call, and assumed it's broken. I'll believe explorer.exe has a bug when there's a specific exploit for it.

    56. Re:Application developers fault by RightSaidFred99 · · Score: 1

      You're probably right. It's not like Microsoft hires the best programmers in the world, they're probably all "stupid developers".

      Sometimes I wonder if people ever go back and read what they've written a few seconds later and realize how daft it was.

    57. Re:Application developers fault by Caerdwyn · · Score: 1

      Nice reasoning there. Take a seat next to the tea party morons and the birthers.

      What does your argumentum-ad-hominem-based politics have to do with DLL linking?

      Stay on topic, please.

      --
      Everybody gets what the majority deserves.
    58. Re:Application developers fault by Anonymous Coward · · Score: 0

      Should you sign all of your dll's?

    59. Re:Application developers fault by clone53421 · · Score: 1

      But how do you write mozfoo.dll to their disk? And if you could, why didn't you just overwrite the original DLL?

      You don’t. You give them access to a network folder or removable device that contains a file they want (the bait) and the evil mozfoo.dll (hidden/system if you wish to prevent its casual discovery) that will get executed if they try to open the bait file.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    60. Re:Application developers fault by Anonymous Coward · · Score: 1, Interesting

      Or you just sign it instead of hashing it. The net result being that you prove authenticity before blindly accepting a file.

    61. Re:Application developers fault by hesaigo999ca · · Score: 1

      >There are no reports of any Microsoft or default Windows applications containing the bug,

      Sometimes I wonder if people ever go back and actually read TFA before they write something daft about it......there fixed that for ya.

    62. Re:Application developers fault by Anonymous Coward · · Score: 0

      You are 100% right. This isn't an OS vulnerability.
      To exploit this, the website would need to convince the browser to load a DLL from the place where internet resources are temporarily stored. There are at least two ways to prevent this.
      1) The browser can make sure that the current folder is never set to such dangerous locations.
      2) The browser and plug-ins can modify the DLL search strategy to not consult the current folder. (See MSDN for details.)
      Since the OS provides everything necessary to prevent this, it is an application flaw. My personal choice for a fix would be number 1) since otherwise you're still open to the possibility that the user opens a document from the browser, and that the associated application loads a hostile DLL.
      Note however that since XP SP2, the DLL search strategy has been changed in order to move the current folder below the application folder and system folders (but still above the path variable). So as long as all DLLs the application references actually exist, you'd still be safe.
      Note also that it's possible for applications to remove the current folder from the search strategy altogether. (I'm surprised that this isn't the default, but maybe this is for backwards compatibility.)

    63. Re:Application developers fault by BitZtream · · Score: 1

      The real problem is that you can't easily modify the library search path at run time, so including the current working directory is a convenent way to deal with that problem on a limited scale. I know I've written plenty of applications that do just that.

      On OSX its far worse out of the box with XCode, which has a tendency to use linker flags that specify EXACTLY where a library will be, which is a retarded thing considering the way that OSX application bundles work out of the box. You have to physically modify libraries in order to get them to load from someplace other than where they were compiled to end up (by default, this can be changed).

      Other OSes are less relevant to the discussion since you build most of your apps from source, which is a far bigger issue than DLL Hell.

      If Windows or OSX both let you modify the search path, in the application, at runtime, the use of cwd at load time on Windows could be replaced with something like @loader_path from OS X 10.5. by default, and applications could update their search path as needed at runtime.

      An app can specify where to look when using LoadLibrary/dlopen, why is there no easy way to modify the damn search path at runtime.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    64. Re:Application developers fault by Anonymous Coward · · Score: 0

      Or you just sign the fucking libraries and this problem disappears entirely.

    65. Re:Application developers fault by Anonymous Coward · · Score: 0

      http://code.google.com/p/unix-privesc-check/

    66. Re:Application developers fault by scdeimos · · Score: 1
      Except when it doesn't:
      • Attacker can sign their own version of the libraries and just ensure they appear in the DLL path before the official libraries (such as the application's own directory).
      • Code signing relies on PKI, and keys expire. Applications can't check for a particular signature because the keys used for code signing change over time. (NOTE: You can code sign things with multiple keys, including expired keys that were previously valid, but people rarely do this and almost never do it properly.)
      • The EXE loader could check signatures on DLLs before giving apps access to them (through LoadLibrary() or whatever), but would need to have a central registry of Allowed Keys to be of any use. Anything a 3rd party developer can call to add their own DLL keys to this Allowed Key registry can be compromised by attackers, too.
    67. Re:Application developers fault by timbrown · · Score: 1

      You can check out a blog post I wrote on a similar attack that could be used against Linux (and other POSIX-alikes):

      http://www.nth-dimension.org.uk/blog.php?id=87

      The two big differences are that in this attack I can't exploit it as easily over the network and that the default case is secure on Linux so developer have to go out of their way to make themselves insecure (although a lot do, because it is the most "obvious" way to change the location from which libraries are loaded).

      --
      Tim Brown
    68. Re:Application developers fault by mdwh2 · · Score: 1

      Thanks for the info, I was wondering if that was the case. Although given that the standard linking case allows for DLLs to be anywhere in the search path, it's still unclear to me why specifying a DLL in LoadLibrary without a specific path is bad, and if it has different behaviour, shouldn't that be an OS flaw? (I.e., ideally an application should be able to use LoadLibrary with the same paths being searched as in the standard linking case when a DLL is needed for the application to start.)

    69. Re:Application developers fault by mdwh2 · · Score: 1

      Not on their system. In the attack scenario the user's current directory, by whatever means, is a foreign system. Maybe it's a PC on the local network, maybe it's a Webdav share on some server in another country.

      Yes I was wondering if it was more the possibility of non-local loading. But in that case, I'd still say it's an OS flaw, not an application flaw - surely it's the OSs job to set the allowed DLL paths up correctly and securely, so that the local disk and trusted networks are included, but things like webdav shares or downloading from a web page in general aren't.

    70. Re:Application developers fault by Kotten · · Score: 1

      I checked documentation and I was wrong. Versioning in .NET is like in other operating systems except that old, compatible, versions of library are kept.

      --
      Note to self: Make a sig
    71. Re:Application developers fault by Anonymous Coward · · Score: 0

      According to Moore, at least one Microsoft executable -- "explorer.exe," the Windows shell -- includes the flaw.
      I'm pretty sure your Windows machine has explorer.exe loaded by default.

      Of course, loading Explorer.EXE and its DLL dependencies by default, running it as a one-instance-per-user app does prevent the exploitation of this flaw. To exploit this flaw, you have to start an EXE from a controlled path. The first Explorer process is safe, and second instances won't start.

  2. Not quite by RenHoek · · Score: 0

    >'The hard part has already been done for [script kiddies].'

    Here, I fixed it for ya. No self-respecting coder would use a library like that.

    1. Re:Not quite by Lazareth · · Score: 5, Insightful

      Yeah, because all self-respecting coders has this driving urge to reinvent the wheel whenever they're met with an already functional and documented piece of code.

    2. Re:Not quite by jeffasselin · · Score: 3, Insightful

      This strange belief that doing things "the hard way" is in some unfathomable way "better" has always been interesting to me.

      A self-respecting coder is a strange beast indeed if it acts the way you describe it doing. A competent coder would just use any tool it has access to (including metasploit) in order to achieve its goals. A nice, competent coder would use this tool or any other to check the applications he uses or writes for security holes. Ignoring this tool because it's "too easy" is stupid.

      And regarding those "self-respecting coders", I don't think they intersect much with the kind of malicious hackers who would be willing to use this exploit for nefarious reasons.

      --
      If he explores all forms and substances Straight homeward to their symbol-essences; He shall not die.
    3. Re:Not quite by L4t3r4lu5 · · Score: 1

      Microsoft issues a patch. This conversation follows:

      Customer: Hey. This app stopped working. What gives?
      Support: Yeah, Microsoft issued a patch which broke it. It's Microsoft's fault that they have a buggy OS.
      C: Hey Microsoft, what gives with this patch breaking my app?
      Microsoft: The code used by that app was vulnerable to exploitation. We fixed it. You developer used code which was exploitable and will need to fix it.
      C: Hey, Microsoft say they made my PC more secure with this patch. Apparently your rubbish code was exploitable. You knowingly sold me software which had a vulnerability which could result in serious security issues? Shit, I hope your legal team is well paid.
      S: A patch is on the way. Please don't sue.

      --
      Finally had enough. Come see us over at https://soylentnews.org/
    4. Re:Not quite by Crudely_Indecent · · Score: 1

      I'd like to introduce you to Dan Bernstein, creator of QMail and DJBDNS.

      Certainly, he could've accepted that BIND, Sendmail and Postfix were functional, but what fun would that be?

      Even if Dan isn't self-respecting, I'm sure there are many (myself included) that respect him.

      --


      "Lame" - Galaxar
    5. Re:Not quite by Anonymous Coward · · Score: 0

      >self-respecting coder
      >coder
      >ya

      Seriously? What are we here, 13?

      Reinventing the wheel over and over again gets boring by the time you actually have a job and life to lead.
      Every (intelligent) programmer uses libraries for things that are useless to reinvent every single time.
      Whether it is using a library method in the language itself or just copy-pasting snippets from a text file, both are useful.

      I suppose you probably also wrote that browser and OS you're using as well?
      After all, no self-respecting elite haxxor would use an OS and software made by someone else, right?

    6. Re:Not quite by FuckingNickName · · Score: 1

      You knowingly sold me software which had a vulnerability which could result in serious security issues?

      S: A patch is on the way. Please don't sue.

      Meanwhile, in the real world...

    7. Re:Not quite by Ecuador · · Score: 2, Insightful

      Yeah, because all self-respecting coders has this driving urge to reinvent the wheel whenever they're met with an already functional and documented piece of code.

      Really? Phewww! I thought I was among few paranoid enough to not trust anything I haven't implemented myself from scratch. Good thing to hear all self-respecting coders work like that and I am not a minority! I mean, it was kind of obvious, how can you trust a library or sample code some unknown guy wrote when you yourself, the master developer, can do the optimal implementation yourself.

      --
      Violence is the last refuge of the incompetent. Polar Scope Align for iOS
    8. Re:Not quite by Anonymous Coward · · Score: 0

      'd like to introduce you to Dan Bernstein [cr.yp.to], creator of QMail and DJBDNS.

      Certainly, he could've accepted that BIND, Sendmail and Postfix were functional, but what fun would that be?

      Well, when your God Dan creates a C library, compiler, POSIX kernel, a new HDL, and then the design for the hardware in that new HDL to run your oh-so-perfect DNS server from the last century, I'll *start* to see your point.

    9. Re:Not quite by Anonymous Coward · · Score: 0

      Yes, I for one have already four or five better wheel designs that you, especially my gradient one.

    10. Re:Not quite by olderchurch · · Score: 1

      In our polytheism world we can have multiple gods, so we have a secure OS that can run QMail and DJBDNS

      --
      Disclaimer: This opinion was created without the use of any facts
    11. Re:Not quite by TheLink · · Score: 1

      > Here, I fixed it for ya. No self-respecting coder would use a library like that.

      Why? Are there bad bugs or security exploits in that library?

      --
    12. Re:Not quite by L4t3r4lu5 · · Score: 2, Insightful

      Idiots continue to put up with the "release now, fix later" model of software development? Continue to have sub-standard produce foisted upon them because an application isn't a product you can hold, and therefore has gotten around merchantability laws on a technicality?

      Yup, the general population repeatedly bending over to big corp budgets sounds like real life to me.

      --
      Finally had enough. Come see us over at https://soylentnews.org/
    13. Re:Not quite by sp3d2orbit · · Score: 3, Insightful

      Its not the rewriting that is important. It is the deconstruction and reconstruction from scratch that is important. If you pour over a piece of someone else's code, document it, talk about it, sleep with it, whatever, you still will not be as intimately familiar with the code as someone who wrote it.

      There is absolutely nothing wrong with starting with someone else's well documented piece of code, reverse engineering it, and implementing a "inspired" version of your own. It goes a long way to understand problems you would never get a chance to understand.

      Think about it this way, all sorting algorithms have been written a million times. Still, students have to struggle through implementations every semester so they learn. This is the same thing. Its not wasting time, it is improving oneself.

    14. Re:Not quite by pclminion · · Score: 1

      I mean, it was kind of obvious, how can you trust a library or sample code some unknown guy wrote when you yourself, the master developer, can do the optimal implementation yourself.

      Translation: "I am a better program than any other programmer on Earth." Yeah, right.

    15. Re:Not quite by RightSaidFred99 · · Score: 1

      Thank God, I mean we've got hundreds of thousands of servers out there tasked with running QMail and DJBDNS, now we can rest assured they're all secure.

      This is truly a good day for the hordes of IT people dutifully running all those QMail and DJBDNS instances!

    16. Re:Not quite by StikyPad · · Score: 1

      If all software had to hold up to merchantability rules, it would cost orders of magnitude more than top-of-the-line hardware and flaws would *still* exist. Hospitals, banks, governments, etc. pay a minimum of hundreds of thousands of dollars for this sort of software, usually for very specific hardware that's been explicitly and thoroughly tested, and the payback is marginal at best. In other words, be careful what the fuck you wish for.

    17. Re:Not quite by StikyPad · · Score: 1

      If you pour over a piece of someone else's code, document it, talk about it, sleep with it, whatever, you still will not be as intimately familiar with the code as someone who wrote it.

      The fact that I can't remember what I wrote last year, let alone how I wrote it, is incontrovertible evidence to the contrary.

  3. And Also Four of Microsoft's Applications by eldavojohn · · Score: 5, Informative

    There are no reports of any Microsoft or default Windows applications containing the bug

    Really? That's odd, from the original blog posting:

    At least four of Microsoft’s own applications have been confirmed as exploitable through this vector, two of which were already being addressed by the time I contacted them.

    --
    My work here is dung.
    1. Re:And Also Four of Microsoft's Applications by Xacid · · Score: 4, Insightful

      The link appears to be slashdotted, but my guess is that the emphasis from the parent is on "default". Microsoft offers more than just a standard vanilla OS install and applications.

    2. Re:And Also Four of Microsoft's Applications by Anonymous Coward · · Score: 0

      The link appears to be slashdotted, but my guess is that the emphasis from the parent is on "default". Microsoft offers more than just a standard vanilla OS install and applications.

      So it's okay to exonerate Microsoft and absolve them of all blame.

      Except they're just as guilty as the devilish third party applications.

    3. Re:And Also Four of Microsoft's Applications by Xacid · · Score: 1

      As much as it's okay to burn them at the stake for this as well. As mentioned earlier - this isn't a problem with the OS, it's a problem with how people are programming. Microsoft is just as culpable for it as everyone else - and from the sounds of it they're already working to fix it. If that doesn't satisfy you enough then go buy a Mac, get off slashdot, and learn to program perfect code yourself.

    4. Re:And Also Four of Microsoft's Applications by Zalbik · · Score: 1

      The link appears to be slashdotted, but my guess is that the emphasis from the parent is on "default". Microsoft offers more than just a standard vanilla OS install and applications.

      Yes, but the original claim was:

      There are no reports of any Microsoft or default Windows applications containing the bug

      This claim is obviously false as there are Microsoft applications containing the bug. What we can say is that issue is not the fault of the Microsoft OS developers.

    5. Re:And Also Four of Microsoft's Applications by klui · · Score: 1

      Just run regedit and search for all instances of rundll32.exe. You will find there are quite a few entries that do not fully qualify the dlls they want to access. Some entries even have rundll32.exe not fully-qualified.

    6. Re:And Also Four of Microsoft's Applications by Anonymous Coward · · Score: 0

      Or actually, it's their fault for allowing DLL's to be called stupidly. Now they have to just live with it or they'd break everything.

    7. Re:And Also Four of Microsoft's Applications by ozmanjusri · · Score: 1
      So it's okay to exonerate Microsoft and absolve them of all blame.
      Except they're just as guilty as the devilish third party applications.

      No, this is a genuine Windows vulnerability. Microsoft is responsible, not third parties.

      It's very similar to putting . in $PATH on Unix. Windows, as usual fails to learn from Unix and puts . in $PATH by default. Third party app developers are not guilty, and neither are users.

      --
      "I've got more toys than Teruhisa Kitahara."
    8. Re:And Also Four of Microsoft's Applications by jrumney · · Score: 1

      Are you sure the emphasis is on the word default, and not the word or that comes before it?

  4. Helps Microsoft, helps malware-biz by h00manist · · Score: 1

    Releasing these exploits mostly helps who is best equipped to use them. Malware-biz and Microsoft. Should just write some stuff to share all data files in p2p networks and let it run.

    --
    Build your own energy sources from scratch. http://otherpower.com/
    1. Re:Helps Microsoft, helps malware-biz by mcgrew · · Score: 1

      TFS says there's a detection tool; run the tool and uninstall any apps that have the vuln and you're safe(er).

    2. Re:Helps Microsoft, helps malware-biz by Anonymous Coward · · Score: 0

      You know that explorer.exe is affected, right?

  5. Requires user action by munky99999 · · Score: 1

    The exploit requires user action. So the exploit isnt going to be as bad as it could have been.

    1. Re:Requires user action by 0123456 · · Score: 1

      The exploit requires user action. So the exploit isnt going to be as bad as it could have been.

      Until some virus starts writing compromised .DLL files to every network share in the company.

  6. Huh? by FranTaylor · · Score: 3, Interesting

    "but considering how much pain in the ass it is on Linux too, it wouldn't really work for all the casual people."

    I have Fedora 12 on my desktop with SELinux enabled. I didn't have to do ANYTHING AT ALL. I haven't seen an un-intentional alert in months. I was worried so I set one off myself just to make sure SELinux is still working, and yes it caught it.

    1. Re:Huh? by BitZtream · · Score: 1

      You do realize that people wouldn't intentionally set off the alert ... right, and that your test was just blowing smoke ...

      I've I'm writing something to attack your SELinux box, I'm going to do everything in my power to not trigger any sort of detection software.

      Its retarded to say 'I know I'm safe, I TESTED IT!' when talking about security and/or viruses. You tested a known attack vector, which pretty much everyone handles. Its the UNKNOWN ones that you can neither test for nor ensure you are secure against.

      A proper virus or malware would ensure you didn't get notified, the only ones you get notified about are the ones that failed.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    2. Re:Huh? by Anonymous Coward · · Score: 0

      He was wondering whether it was switched on.

      What he did is the same as testing the smoke alarm by pressing the button. The smoke alarm sounds => it works.

      What you're saying is the equivalent of "Yeah, but what if the fire starts in the bed you're sleeping in, by the time it creates enough smoke to sound the alarm, you'll suffocate". Which is both missing the point of a smoke alarm AND missing the point of the test.

      SELinux isn't perfect, the poster's claim to have tested it doesn't equate to a claim that it's perfect. He was just pointing out that it's not that much of a pain, since it was so invisible to him that he had to check it was there. Lots of people now run with SELinux enabled, and they aren't vulnerable to a bunch of potential security holes that could occur, as a result of that choice.

    3. Re:Huh? by Stray7Xi · · Score: 1

      I have Fedora 12 on my desktop with SELinux enabled. I didn't have to do ANYTHING AT ALL. I haven't seen an un-intentional alert in months.

      Fedora uses targeted policy by default, meaning there's confined and unconfined processes. Services/daemons are confined, User processes are unconfined (full permissions). Why? Because it's too freaking hard to set selinux contexts for user processes.

      So your web browser, email, and bittorrent all are unaffected by selinux in most distros. I wouldn't recommend trying to setup contexts for them either, selinux is a nightmare. Apparmor at least you can get sane profiles for user applications.

  7. wait, open a remote file through SMB ? by Anonymous Coward · · Score: 1, Informative

    From the Microsoft FAQ:

    How could an attacker exploit this vulnerability?

    This vulnerability requires that the attacker convince the user to open a file using a vulnerable program, from a remote network location. When the application loads one of its required or optional libraries, the vulnerable application may attempt to load the library from the remote network location. If the attacker provides a specially crafted library at this location, the attacker may succeed at executing arbitrary code on the user's machine.

    I don't know about you, but I never open files from an untrusted SMB...

    1. Re:wait, open a remote file through SMB ? by nomaddamon · · Score: 1

      Consider opening a media file, with your trusted program from SMB. If the attacker has planted a malicious .dll file in the same SMB share and your "trusted" media playing application is vulnerable then you have just compromised yourself.

    2. Re:wait, open a remote file through SMB ? by ArsenneLupin · · Score: 2, Interesting

      Even worse, consider visting a web page with <img src="file://maliciousSmbServer/share/test.jpg"> somewhere in it...

    3. Re:wait, open a remote file through SMB ? by gravyface · · Score: 1

      Egress filtering at the perimeter FTW. It's amazing what people let *out* of their networks...

      --
      body massage!
    4. Re:wait, open a remote file through SMB ? by clone53421 · · Score: 1

      That doesn’t use the OS shell extension handler.

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    5. Re:wait, open a remote file through SMB ? by clone53421 · · Score: 1

      * Of course, <iframe src="file://maliciousSmbServer/share/bad.pdf"></iframe> very well might... but the browser shouldn’t let it do that. (Just tested in Firefox. Security error.)

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    6. Re:wait, open a remote file through SMB ? by ArsenneLupin · · Score: 2, Insightful

      Egress filtering at the perimeter FTW.

      Now consider that the same exploit also works over WebDAV (which basically is just glorified http...), and suddenly egress filtering starts looking rather blunt against this threat...

    7. Re:wait, open a remote file through SMB ? by Anonymous Coward · · Score: 0

      This makes no sense. Why is Windows changing the current directory path when navigation occurs in an opened file dialog? It should have zero influence on the program state.

    8. Re:wait, open a remote file through SMB ? by arth1 · · Score: 1

      Contrary to what you seem to think, it's not only exploitable over SMB.
      A user downloading and extracting an archive with non-executable files (images, mp3s, videos, whatever) are just as vulnerable if there's a DLL in the archive too.

      It's also likely that other delivery mechanisms exist too -- consider an e-mail client that saves all embedded images and other files to a temporary folder, for example.

    9. Re:wait, open a remote file through SMB ? by shutdown+-p+now · · Score: 1

      Even worse, consider visting a web page with somewhere in it...

      This won't do anything useful. You need to somehow make the user run an application with the path where he planted his malicious DLL as the current directory. Your example would just display the image file in the browser (which has already been launched prior to that) as usual.

      You could, however, try redirecting to a file: URL via JS, and hope that user clicks "Open" in the dialog window that will pop up.

  8. Their security recommendation is hardly a solution by postmortem · · Score: 2, Interesting

    Here's what Microsoft recommends:
    "Wherever possible, specify a fully qualified path when using the LoadLibrary, LoadLibraryEx, CreateProcess, or ShellExecute functions. "
    "Consider removing the current directory from the DLL search path by calling"

    In other words, they want programmers to use LoadLibrary("C:\program Files\my software\somedll.dll") instead of LoadLibrary("somedll.dll"). This is very counter-intuitive, as if you were app developer, you would want all of your DLLs be distributed with binary, and reside in same directory. Take a look in your program files directory, and almost every app does it that way...

  9. I can see this being useful for propagation... by gravyface · · Score: 1

    in an "open" LAN environment: an exploited machine sets up a share, emails links to others in the contact list, remote exploit ensues. But who's allowing egress (outbound) SMB, WebDAV (at least not to a whitelist of remote hosts) on their network? Putting Windows Firewall up on all the workstations to drop ingress SMB traffic (with a few host exceptions for those pushing out updates via SMB) would be a smart thing to do as there's really no reason for workstations to be sharing files in a network with file servers.

    --
    body massage!
  10. Re:The problem is not leap seconds... by xSander · · Score: 1

    I think the post above was intended for this article...

  11. Re:Their security recommendation is hardly a solut by clone53421 · · Score: 1

    In other words, they want programmers to use LoadLibrary("C:\program Files\my software\somedll.dll") instead of LoadLibrary("somedll.dll"). This is very counter-intuitive, as if you were app developer, you would want all of your DLLs be distributed with binary, and reside in same directory. Take a look in your program files directory, and almost every app does it that way...

    Um, that’s why they have the %programfiles% environment variable, and it’s why you install applications there, and it’s why the current directory when you launch a file (%userprofile%\Default\Documents\) should never be where you’re getting executable content (such as a .dll file).

    When you launch a file via its shell extension, the “current” directory and the directory where the executable is located which opens that file type are not the same... and you shouldn’t be looking in the current directory for your .dll files. Period.

    --
    Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
  12. Microsoft's OWN fault !! by Anne+Honime · · Score: 5, Insightful

    MOD PARENT UP !! Fact is, on any unix out there, no competent admin would leave '.' neither in executable path, nor in dynamic library search path. It's another of case of a security hole known at least theoretically since the 60's, and observed in real life in the 80's, that microsoft overlooked in the design stage when it was time to follow proper security assessments, and are now stuck with.

    They should be put on trial for dumb blunders like this one. When you hire top professionals who can't ignore the 'state of art' when doing an error like this, it should be considered a cause for limitless civil liability.

    1. Re:Microsoft's OWN fault !! by shutdown+-p+now · · Score: 1

      Fact is, on any unix out there, no competent admin would leave '.' neither in executable path, nor in dynamic library search path.

      I've yet to see any Unix which has . in either PATH or LD_PATH by default.

      microsoft overlooked in the design stage

      It's not overlooked. It's just one of those compatibility things that date back several decades.

      However, the corollary is that any Windows developer who is clueless of DLL search path in Win32 (and the implications) should really know better by now.

    2. Re:Microsoft's OWN fault !! by Anonymous Coward · · Score: 0

      Lol the 60s? Try learning about when the concept of dynamic libraries came to pass, french cunt.

    3. Re:Microsoft's OWN fault !! by Anne+Honime · · Score: 1

      "Programmers originally developed dynamic linking in the Multics operating system, starting in 1964, and the MTS (Michigan Terminal System), built in the late 1960s."

      wikipedia

      Those who can't learn from history are doomed to repeat it.

  13. Three letters by Anonymous Coward · · Score: 0

    DEP

    1. Re:Three letters by Galestar · · Score: 1

      2 letters: NO
      as in NO, that doesn't do anything to fix this.

      --
      AccountKiller
    2. Re:Three letters by Anonymous Coward · · Score: 0

      Since when doesn't DEP fix buffer overflow exploits?

    3. Re:Three letters by Galestar · · Score: 2

      It does, but this has nothing to do with buffer overflows. Please RTFA.

      --
      AccountKiller
    4. Re:Three letters by valeo.de · · Score: 2

      Since when is does this exploit involve overflowing buffers?

      --
      cat: /home/valeo/.sig: No such file or directory
    5. Re:Three letters by Anonymous Coward · · Score: 0

      Hand in your geek card immediately.

    6. Re:Three letters by inject_hotmail.com · · Score: 1

      Hand in your geek card as well.

  14. Re:Their security recommendation is hardly a solut by 0ld_d0g · · Score: 3, Informative

    Well, fully qualified doesn't mean static. You could compute the fully qualified name at runtime to pass to the LoadLibrary call. Or you could just stick a SetDllDirectory call somewhere in your app startup and keep the rest of the code the same.

  15. I'm sorry what's the problem? by js3 · · Score: 2, Interesting

    If the user's machine is compromised to the point where unauthorized dlls are replacing valid dlls that's not my problem as a software developer. The only validity to this bug is that windows allows dlls to be loaded from remote network locations (isn't this sort of stupid in the first place?).

    I think the severity of this bug is blown out of proportion. The only idiots to blame is the idiot who did not secure his computer.

    --
    did you forget to take your meds?
    1. Re:I'm sorry what's the problem? by ledow · · Score: 1

      You map a network drive on your LAN, you execute a program on it that requires a DLL. That DLL can't be found unless Windows looks on the remote drive too, and chances are that if a program is bundled with a DLL, that DLL is actually a better match for the program than anything lurking in the Windows folder or other paths. So there is a use-case here - I'm pretty sure there's at least one school system I've worked on that would just break in a second if you couldn't load DLL's from a remote network location, and for not much reason ("The installation files are all there, I can see them, they are in the read-only mapped public drive we've always used for software distribution, etc." - and at least one school administration package I know runs from a shared Windows drive on the server thus requiring zero installation on the client)

      I agree that the things being blown out of all proportion - if someone can place a file on your drive in any way, shape or form, it's game over anyway, Windows File Protection or not. More importantly, why the HELL haven't we fixed this DLL mess yet to only load DLL's from the application folder and then let people hard-link to a shared copy if they really want to share libraries between applications?

    2. Re:I'm sorry what's the problem? by arth1 · · Score: 4, Informative

      If the user's machine is compromised to the point where unauthorized dlls are replacing valid dlls that's not my problem as a software developer. The only validity to this bug is that windows allows dlls to be loaded from remote network locations (isn't this sort of stupid in the first place?).

      It's not replacing. It's you, as a developer, saying "try to load foo.dll", without specifying where "foo.dll" is to be found, but relies on the OS to find it for you. It traverses a list of possible locations, and as a last resort tries the current working directory.
      The problem is all yours if you don't specify where the OS is to look for the DLL. If you want to load DLLs from %installdir%\dlls, then all you have to do is specify that path. It's not rocket science.

      And no, allowing DLLs to be loaded from remote locations isn't stupid, as it allows for shared installations, which both saves boatloads of disk space, and allows for updating a single place instead of on each machine.
      Not considering that possibility is what's stupid.
      And not understanding how the DLL loading and file systems work on the OS you program for is even worse.

      Finally, the exploit doesn't depend on a remote share either -- that's Smallsquishy's damage control PR department working overtime. If you download a zip with hundreds of MP3 or picture files, extract it, and double-click one of them, the DLL that was in the archive will get loaded if your default player/viewer queries for that DLL without specifying a path.

      It's not a new exploit either -- it's been around for a long time on Windows. And before that, there were vulnerable Linux systems with "." in LD_LIBRARY_PATH, which basically amounts to the same thing.

    3. Re:I'm sorry what's the problem? by BitZtream · · Score: 1

      So you're running code from a compromised share ... and you're worrying about DLL's you load from that share as well?

      Look, reality check ... they'll just fuck with the EXE directly instead of waiting for something to load the DLL. Why go in through the back door when the front door is open first and otherwise offers no differences.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    4. Re:I'm sorry what's the problem? by Anonymous Coward · · Score: 0

      Smallsquishy.

      Took me a moment, but LOLZ!!!

  16. the problem by Anonymous Coward · · Score: 1, Insightful

    The problem is that in attempting to load a remote media file, the application is tricked into loading a malicious DLL located in the same directory as the media file.

    `2. If the application tries to load a DLL whose name consists of a NULL, it will search for a file named ".DLL". This is exploitable in most cases and affects at least one Microsoft product.'

  17. Re:Their security recommendation is hardly a solut by mdwh2 · · Score: 1

    But if it's true that the folder of the data file is included in the search path for DLLs (as opposed to the folder of the application), isn't that something that Microsoft should fix?

    How would an application developer fix it to avoid this problem, whilst still allowing the possibility of loading DLLs from the application folder (honest question, I'm not saying it isn't possible, just curious of the solution)?

    Do you know how things work with linking the usual way with a lib file (as opposed to manually calling LoadLibrary)?

  18. Just wow... by Anonymous Coward · · Score: 0

    Apparently anything can be passed as a serious exploit today. This is the way LoadLibrary() has been worked ever since it's implementation, the OS will first query the target path (this doesn't need to be the path the application resides in, this can be set in the shortcut) and go all the way to the system folders --- in fact M$ mentions that this can be used to make applications load arbitary libraries on the very page where LoadLibrary() is documented on MSDN. Beside all this however, this is a rather moot exploit, if someone can place files in arbitary directories on your system, you're already compromized, and they don't need to do this to execute whatever code they wish to execute on the system, the exploit placing the files would usually involve RCE anyway (social engineering excluded, but if you can get people to put random files in locations for you, why not ask them to "run this harmless installer" right away?).

    The WebDAV issue is a much more severe problem, but it has been known and circulating for many month now and isn't a new problem, the hidden service (it doesn't show up in services.msc) can be disabled by setting a value in the registry.

    1. Re:Just wow... by 0123456 · · Score: 1

      The WebDAV issue is a much more severe problem, but it has been known and circulating for many month now and isn't a new problem, the hidden service (it doesn't show up in services.msc) can be disabled by setting a value in the registry.

      Mmm, secret, hidden, insecure services which can only be disabled by magic registry settings.

      It's so long since I've used Windows much that I'd completely forgotten what a security nightmare it was.

  19. How this works by Elbows · · Score: 5, Informative

    I took me a while to figure out how this exploit works, but I think it goes like this:

    I have an application, foo.exe, that can make use of an optional system component (or 3rd-party DLL), bar.dll. I don't ship that DLL, and I can't guarantee that it will be present on every user's system. So to ensure that my program degrades gracefully, I open it with LoadLibrary("bar.dll"), and if it's not found I disable the features that depend on it. Since it's not my DLL, I can't speculate on where it's installed, so I use an unqualified path and let the loader do the searching (this is, after all, the job of the loader). The ensures that, as long as bar.dll is correctly installed on the system, my application will find and use it.

    From an application developer's point of view, this the right way to do things. If I did this on Linux or MacOS, it wouldn't be a problem. Unfortunately, Microsoft decided that the current directory (".") should be in the default search path (see http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx ). It's even searched before $PATH!

    Now the exploit goes like this:
    1. On \\evilserver\evilsmbshare, I place a file foofile.foo, an extension which is associated with foo.exe. Right next to it, I create an evil version of bar.dll.
    2. I convince the user to double-click on foofile.foo, causing windows to open foo.exe, with a current directory of \\evilserver\evilsmbshare.
    3. If the user's system doesn't have bar.dll installed, Windows will eventually find my evil version of it at .\bar.dll and load it into the unsuspecting foo.exe.
    4. My evil code runs and does whatever evil deeds I want it to.

    If this is correct, then the decision my Microsoft to put the current directory in the library search path seems pretty braindead, and it's hard to blame application developers for assuming that LoadLibrary() will load a library in a sane and secure way. But I'm having a hard time imagining an application that would break if the current directory were just removed from the search path. Shipping DLLs in the application directory is common practice, but expecting them in the current directory? Why would you do that?

    It seems that this exploit requires you to trick the user into opening a file from a filesystem you have access to, at which point you could probably just as easily get them to open a trojan directly. I think local privilege-escalation attacks are more probable (e.g. tricking a system service into opening your evil DLL).

    1. Re:How this works by master_p · · Score: 1

      Thank you, please mod parent up.

    2. Re:How this works by 0123456 · · Score: 1

      But I'm having a hard time imagining an application that would break if the current directory were just removed from the search path. Shipping DLLs in the application directory is common practice, but expecting them in the current directory? Why would you do that?

      I've used a number of programs which would fail to run if you didn't start them from their install directory; I don't know whether they're looking for DLLs or data files, but I can be pretty sure that at least some programmers have relied on this behaviour without even realising... 'yeah, but we always run from our install directory, right?'

    3. Re:How this works by cdrguru · · Score: 2, Interesting

      You are assuming the "current directory" is set to the location where an associated file is located. That isn't true. When an application is invoked by an association the current directory is usually the location of the program executable itself, which is passed the fully qualified name of the file that was clicked and caused the invocation of the program.

      So placing a DLL in the same folder as the associated file doesn't do anything. You have to put it in the same folder as the executable, which is (as of Vista and Windows 7) write-protected.

      With XP it is a lot easier because the Program Files directory structure is not protected and it was common to have applications writing stuff there, so you couldn't protect it. As of Vista the rules changed and you can't write there anymore.

      Yes, I understand the exploit. But again, if you have people dropping files willy-nilly into the file system you are going to have troubles. Same goes for Linux - if you install something that has setuser root it is pretty much an exploit for the entire system. Why would anyone do this? Because the installer tells them it is necessary and just does it. Same thing happens with Windows. If you aren't controlling what is installed, you aren't in control. Period.

    4. Re:How this works by RavenChild · · Score: 1

      Isn't this what signing DLLs was supposed to protect against?

    5. Re:How this works by thoromyr · · Score: 1

      It seems to me that using a web browser to download the bar.dll along with foofile.foo where the user is then going to double click on foofile.foo to open it removes the need for smb/webdav

    6. Re:How this works by Elbows · · Score: 4, Informative

      I just tried this out. When I launch a test program by double-clicking an associated file, the current directory (as returned by GetCurrentDirectory()) is set to the directory where the file was located. It ignores the location of the .exe, and it also ignores the "Start In" directory from the shortcut file (if the association was to a shortcut and not directly to an exe). This is on Win7 64-bit. So I think my evilsmbshare example from above would work as described. Of course it's possible that other Windows systems exhibit completely different behavior. :)

      I agree that it's still hard to exploit, but not quite as hard as requiring access to the user's local filesystem.

    7. Re:How this works by TheThiefMaster · · Score: 2, Informative

      So placing a DLL in the same folder as the associated file doesn't do anything. You have to put it in the same folder as the executable, which is (as of Vista and Windows 7) write-protected.

      With XP it is a lot easier because the Program Files directory structure is not protected and it was common to have applications writing stuff there, so you couldn't protect it. As of Vista the rules changed and you can't write there anymore.

      Actually it's write-protected in XP as well, as long as you don't use the FAT32 filesystem (so per-user file permissions actually exist) and as long as you're not running as admin (which nearly everyone did on their home PCs, but in organisations most people aren't). Vista basically changed the system from "local admin user = root" to "local admin user = sudoer".

    8. Re:How this works by RightSaidFred99 · · Score: 1

      Yes...in .NET.

    9. Re:How this works by Lost+Race · · Score: 1

      It seems that this exploit requires you to trick the user into opening a file from a filesystem you have access to, at which point you could probably just as easily get them to open a trojan directly.

      Infected removable media would be the most likely vector. You plug in a USB flash drive or load a CDROM, browse to a file you want to open but don't notice the malicious DLL in the same directory, perhaps because it's hidden among hundreds of other files. We're used to being cautious about opening files on removable media (make sure it's not .EXE!) but now we have to be even more cautious (make sure there are no .DLL files in the same directory!).

    10. Re:How this works by Anonymous Coward · · Score: 0

      One example is winamp plugins. You just stick a .dll plugin in the winamp directory and on start up it tries to load every .dll found in the directory, for example an audio effect. Its very convienient for the user but also the attacker.

    11. Re:How this works by poor_boi · · Score: 1

      You can't associate files with shortcuts.

  20. Four or Forty? by Anonymous Coward · · Score: 0

    The ComputerWorld link reads 40 Microsoft apps contain the flaw. The only exposed Microsoft app is the shell, explorer.exe.

  21. Re:The problem is not leap seconds... by geminidomino · · Score: 1

    . Is there still a reason why we should keep adjusting our concept of time according to what the earth does?

    Like, duh... otherwise, in 260 million years, Christmas will be in the middle of the summer. That will fuck up Santa's ride!

  22. Here's a good test by Gazzonyx · · Score: 1

    Have you updated your kernel lately?

    --

    If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.

  23. CWDIllegalInDllSearch by colfer · · Score: 1

    Has anybody written a test to verify that Microsoft's fix has been properly applied? It would be a simple DLL with that pops up a message, and simple EXE that loads the DLL (which has new unique name). Or even two versions of the DLL, one with a good message and one with a bad message. One goes in the system path, one goes in the same path as the EXE, a temp folder.

    The MS kb patch has one typo, you add a new DWORD value to the registry, not a new key.
    http://support.microsoft.com/kb/2264107

    MS fixed the other typo mentioned here:
    http://isc.sans.edu/diary.html?storyid=9445

    1. Re:CWDIllegalInDllSearch by colfer · · Score: 2, Informative

      Or, correction, the good DLL would have to go into a folder that is in the PATH and not in any of the higher priority system folders. And you would have to register a file handler and a new type... since the directory of the EXE has first priority. Oh well.

      The priority list goes:

      1. The directory from which the application loaded
      2. The system directory
      3. The 16-bit system directory
      4. The Windows directory
      5. The current working directory (CWD)
      6. The directories that are listed in the PATH environment variable

      And the patch + adding the new reg value disables #5.

      The whole fix should be rolled up into a little switching program. We should not have to edit the registry to fix this vulnerability. And we should be able to turn the fix off easily if it causes problems.

    2. Re:CWDIllegalInDllSearch by Dreadrik · · Score: 1

      You could just make two .reg files, enable_fix.reg and disable_fix.reg, one which adds the relevant DWORD and one that removes it.

      Now you can just double-click the appropriate .reg file to enable/disable the fix, and hope that regedit.exe itself is not vulnerable to this type of attack...

  24. Re:The problem is not leap seconds... by epo001 · · Score: 1

    Like duh! Christmas IS in the middle of summer in some parts of the world.

  25. Re:The problem is not leap seconds... by Anonymous Coward · · Score: 0

    Ha, like those heathens celebrate Christmas...

  26. Simple Fix by BitZtream · · Score: 1

    Signed binaries.

    The app can verify the signer is the original author and not load it. You make some sort of general localized signer that will pass the 'trust' test for every binary so the user can override it as needed, like to replace a DLL with their own hacked version.

    Give some sort of way to disable the signing check on a per app basis, that has to be done by the user, probably via UAC. Don't give any way to disable it globally or any way that it can be automated.

    People will still be able to do all they need to do, but apps will have to be signed or they'll be too much of a pain in the ass for users to waste their time on them, and in a pinch you CAN still get around it.

    Of course, all of this is just to protect users from themselves essentially since by the time you've got someone loading EXEs from untrusted sources, there are probably easier ways to have you're way with them.

    --
    Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
  27. Clone53421: Post complete info., ok? by Anonymous Coward · · Score: 0

    "Um, that's why they have the %programfiles% environment variable, and it's why you install applications there, and it's why the current directory when you launch a file (%userprofile%\Default\Documents\) should never be where you're getting executable content (such as a .dll file)." - by clone53421 (1310749) on Tuesday August 24, @09:34AM (#33354120)

    See subject, because your WEAK 'explanation' is rather incomplete:

    First of all, using environmental variables alone won't work in a programming IDE such as Visual Studio or others like it. Not without parsing the environment first via API calls (GetEnvironmentStrings or better still, GetEnvironmentVariable for a specific one, etc./et al)...

    Now, also as to libraries to BOTH yourself and the person you replied: Did he even mention current directory vs. the %program files% or %path% location? I don't even SEE it in the quote of his words you utilized, so that also makes you non-sequitur here

    Clone53421, seriously here:

    I mean, hey - Based on your reply above? Either you're just another dumbass network techie type that is limited to writing batch files, and now you're trying to play programmer around here because of the stupidity due to incompleteness of your post. IF that's the case, and I tend to think it is due to the incompleteness of your post and its seeming non-sequitur statements vs. that which you quoted from the person you replied to??

    Don't try to play "expert" in areas you have NO REAL CLUE in, ok? Your lack of complete information shows us all this in fact, quite easily. Your type online???

    Your type's the MOST dangerous type!

    I state that, mainly because you only post partial information, instead of complete accurate info.

    The type of reply you made tells me you are just a noob due to your incomplete data. It also shows your inexperience hands on in coding in languages that can utilize the Win16/32/64 API calls like C/C++, Delphi, VB, and many others.

    (Again - I say this because you only posted a minor part/partial part of what actually needs to be done, in full, in order to be able to use such environmental "%vars%" from inside a 'real programming language' (& not just a .bat 16 bit or .cmd 32/64 bit files and their commandline interpreter like DOS tty terminals/consoles/command prompts use and what you do in batch files)).

    APK

    P.S.=> The rest of your post's "ok" but you ought to have posted a referential link to Microsoft in order to show the user the search rules for libraries, like this one -> http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx

    PERTINENT EXCERPT/QUOTE MATERIAL ON DLL SEARCH ORDER CONVENTIONS, and CAVEATS/EXCEPTIONS DUE TO SETUP TYPES:

    ---

    If SafeDllSearchMode is enabled, the search order is as follows:
    The directory from which the application loaded.
    The system directory. Use the GetSystemDirectory function to get the path of this directory.
    The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
    The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
    The current directory.
    The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.

    If SafeDllSearchMode is disabled, the search order is as follows:
    The directory from which the application loaded.
    The current directory.
    The system directory. Use the GetSystemDirectory function to get the path of this directory.
    The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
    The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
    The

    1. Re:Clone53421: Post complete info., ok? by Anonymous Coward · · Score: 0

      First of all, using environmental variables alone won't work in a programming IDE such as Visual Studio or others like it. Not without parsing the environment first via API calls (GetEnvironmentStrings or better still, GetEnvironmentVariable for a specific one, etc./et al)...

      Yes, that’s how you “use environment variables”, dipshit. Thanks for saying I’m wrong then explaining that what I said to do was correct.

      Either you're just another dumbass network techie type that is limited to writing batch files, and now you're trying to play programmer around here because of the stupidity due to incompleteness of your post.

      Hey, retard! It’s “Either ... Or”. You just gave “Either”. Or what? Where’s the other possibility that you gave in your post? ... and then you said that my post was incomplete. Hilarious.

      you only posted a minor part/partial part of what actually needs to be done, in full, in order to be able to use such environmental "%vars%" from inside a 'real programming language'

      Find the place where I said that my post was a “full” explanation of what “actually needs to be done” in order to do what any “real” programmer already knows needs to be done in any “real programming language” in order to do what I said needed to be done. Hint: I didn’t.

      I state that, mainly because you only post partial information, instead of complete accurate info.

      I posted enough that any non-technical user would adequately understand what should have been done, and enough that any technical user would adequately understand how to do it (because, hell, any “real” programmer should already know how to use an environment variable).

      But your own post is incomplete! You forgot to tell how to write the IDE and the compiler, you forgot to tell how to build the computer it runs on, you forgot to tell how to design and etch the PCBs, microcontrollers and other integrated circuits in the system and wire and solder the connections, you forgot to describe how to engineer a power plant and run electric lines to your equipment, and you forgot to describe how to create a river to cool the generators that produced the electricity that you needed.

      Of course you ASSUMED that all of that would be unnecessary information, but in fact your post was just incomplete by your own standard (i.e. needs to include reams of redundant, unnecessary information that its audience either doesn’t need or already has).

      Delphi, VB

      You just disqualified yourself from “real” programming.

      P.S.=> The rest of your post's "ok" but you ought to have posted a referential link to Microsoft in order to show the user the search rules for libraries, like this one -> http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx

      Somebody else already posted it, moron. And only an idiot (which you are) would post a link and then quote NEARLY THE ENTIRE PAGE that was linked to.

      GTFO, troll.

  28. You didn't say HOW to obtain %vars% in code by Anonymous Coward · · Score: 0

    "You just disqualified yourself from "real" programming." - by Anonymous Coward on Wednesday August 25, @12:20PM (#33370176)

    LOL, you did a fine job of that in your usage of %ProgramFiles% alone because it's NOT a "singleword" as you wrote it, it's actually %Program Files% first of all, & lmao, secondly? See below next, as it puts the "icing on your cake":

    See subject-line, because it says all I had to say, & I said it with PROGRAMMATIC SPECIFICS, unlike yourself in what API's are needed to use Environment vars in languages I noted and others also whereas by way of comparison?

    You did not, that was my point.

    (I.E.-> You only did what a network admin type might or some techie writing a batch file or .cmd file is all, rather than to indicate what a full blown programmer would, which is who folks are "blaming" as well as Microsoft themselves).

    Your further name tossing's your REAL "tell" here though that tells me I hit you RIGHT "on the head", as to your true skillset (limited in scope to batch file writing at best in terms of "programming").

    See below as to a quote of your ad hominem attack on myself via profanities:

    "Yes, that's how you "use environment variables", dipshit. " - by Anonymous Coward on Wednesday August 25, @12:20PM (#33370176)

    Yea, IF you're only writing batch files, as to how YOU said it's used... "real programmers" with REAL languages (not batch or scripting) use API calls, unlike yourself, obviously.

    ---

    "I posted enough that any non-technical user would adequately understand what should have been done, and enough that any technical user would adequately understand how to do it (because, hell, any "real" programmer should already know how to use an environment variable)" - by Anonymous Coward on Wednesday August 25, @12:20PM (#33370176)

    LOL, see above - YOU? You've shown us all you're not, based on all of the above AND you're original post as well.

    APK

  29. I gave you a break and you ran clone? by Anonymous Coward · · Score: 0

    "LOL, you did a fine job of that in your usage of %ProgramFiles% alone because it's NOT a "singleword" as you wrote it, it's actually %Program Files% first of all" - by Anonymous Coward on Wednesday August 25, @01:45PM (#33371532)

    I even made a mistake, on purpose, to see if you'd verify and catch it... LOL, and you STILL ran, clone53421?

    (See above, because it's as you wrote it initially (%ProgramFiles%) & a simple 'set' command issued @ a command prompt verifies it... and my init. reply "shook you up" so bad, you didn't even have the sack to verify that, and you still ran? Please... I sat for 6 hours and waited for you to catch that and STILL you did not! Between thate and your rant and verbose attempts at covering your behind, it told me worlds and that I am correct that you're no coder. You're, at best, a techie that writes batchfiles ONLY!)

    ----

    "You just disqualified yourself from "real" programming." -by clone53421 (1310749) on Tuesday August 24, @09:34AM (#33354120) Journal

    Ahem/again: I said it with PROGRAMMATIC SPECIFICS, unlike yourself in what API's are needed to use Environment vars in languages I noted and others also whereas by way of comparison? You did not, that was my point.

    (A "real programmer" would have. You did not. I.E.-> You only did what a network admin type might or some techie writing a batch file or .cmd file is all, rather than to indicate what a full blown programmer would, which is who folks are "blaming" as well as Microsoft themselves).

    Additionally, the day you can show you've done all this as I have (inclusive of commercially sold software for more than a decade & 1/2 to my credit)? Is the day you can speak to me in that manner and get away with it as a peer, which you obviously are not:

    "My Name is Ozymandias: King of Kings - Look upon my works, ye mighty, & DESPAIR..."

    ----

    Windows NT Magazine (now Windows IT Pro) April 1997 "BACK OFFICE PERFORMANCE" issue, page 61

    (&, for work done for EEC Systems/SuperSpeed.com on PAID CONTRACT (writing portions of their SuperCache program increasing its performance by up to 40% via my work) albeit, for their SuperDisk & HOW TO APPLY IT, took them to a finalist position @ MS Tech Ed, two years in a row 2000-2002, in its HARDEST CATEGORY: SQLServer Performance Enhancement).

    WINDOWS MAGAZINE, 1997, "Top Freeware & Shareware of the Year" issue page 210, #1/first entry in fact (my work is there)

    PC-WELT FEB 1998 - page 84, again, my work is featured there

    WINDOWS MAGAZINE, WINTER 1998 - page 92, insert section, MUST HAVE WARES, my work is again, there

    PC-WELT FEB 1999 - page 83, again, my work is featured there

    CHIP Magazine 7/99 - page 100, my work is there

    GERMAN PC BOOK, Data Becker publisher "PC Aufrusten und Repairen" 2000, where my work is contained in it

    HOT SHAREWARE Numero 46 issue, pg. 54 (PC ware mag from Spain), 2001 my work is there, first one featured, yet again!

    Also, a British PC Mag in 2002 for many utilities I wrote, saw it @ BORDERS BOOKS but didn't buy it... by that point, I had moved onto other areas in this field besides coding only...

    Lastly, being paid for an article that made me money over @ PCPitstop in 2008 for writing up a guide that has people showing NO VIRUSES/SPYWARES & other screwups, via following its point, such as THRONKA sees here -> http://www.xtremepccentral.com/forums/showthread.php?s=ee926d913b81bf6d63c3c7372fd2a24c&t=28430&page=3

    ----

    What do I have to say about that much above? I can't say it any better, than this was stated already (from the greatest book of all time, the "tech manual for life" imo):

    "But by the grace of God I am wha

    1. Re:I gave you a break and you ran clone? by Anonymous Coward · · Score: 0

      You’re a moron. Of course what I posted was correct and your stupid “on purpose mistake” was wrong. The reason I didn’t see it and call you an idiot (which you are) was because I didn’t even see your response before you self-replied not even a day later. I’m not obsessive (like you are) about checking my anonymous coward responses daily.

  30. clone53421 using ac posts now? LMAO! by Anonymous Coward · · Score: 0

    "You just disqualified yourself from "real" programming." -by clone53421 (1310749) on Tuesday August 24, @09:34AM (#33354120) Journal

    Ahem/again: I said it with PROGRAMMATIC SPECIFICS, unlike yourself in what API's are needed to use Environment vars in languages I noted and others also whereas by way of comparison? You did not, that was my point.

    (A "real programmer" would have. You did not. I.E.-> You only did what a network admin type might or some techie writing a batch file or .cmd file is all, rather than to indicate what a full blown programmer would, which is who folks are "blaming" as well as Microsoft themselves).

    Additionally, the day you can show you've done all this below, as I have (inclusive of commercially sold software for more than a decade & 1/2 to my credit)? Is the day you can speak to me in that manner and get away with it as a peer, which you obviously are not:

    "My Name is Ozymandias: King of Kings - Look upon my works, ye mighty, & DESPAIR..."

    ----

    Windows NT Magazine (now Windows IT Pro) April 1997 "BACK OFFICE PERFORMANCE" issue, page 61

    (&, for work done for EEC Systems/SuperSpeed.com on PAID CONTRACT (writing portions of their SuperCache program increasing its performance by up to 40% via my work) albeit, for their SuperDisk & HOW TO APPLY IT, took them to a finalist position @ MS Tech Ed, two years in a row 2000-2002, in its HARDEST CATEGORY: SQLServer Performance Enhancement).

    WINDOWS MAGAZINE, 1997, "Top Freeware & Shareware of the Year" issue page 210, #1/first entry in fact (my work is there)

    PC-WELT FEB 1998 - page 84, again, my work is featured there

    WINDOWS MAGAZINE, WINTER 1998 - page 92, insert section, MUST HAVE WARES, my work is again, there

    PC-WELT FEB 1999 - page 83, again, my work is featured there

    CHIP Magazine 7/99 - page 100, my work is there

    GERMAN PC BOOK, Data Becker publisher "PC Aufrusten und Repairen" 2000, where my work is contained in it

    HOT SHAREWARE Numero 46 issue, pg. 54 (PC ware mag from Spain), 2001 my work is there, first one featured, yet again!

    Also, a British PC Mag in 2002 for many utilities I wrote, saw it @ BORDERS BOOKS but didn't buy it... by that point, I had moved onto other areas in this field besides coding only...

    Lastly, being paid for an article that made me money over @ PCPitstop in 2008 for writing up a guide that has people showing NO VIRUSES/SPYWARES & other screwups, via following its point, such as THRONKA sees here -> http://www.xtremepccentral.com/forums/showthread.php?s=ee926d913b81bf6d63c3c7372fd2a24c&t=28430&page=3

    ----

    What do I have to say about that much above? I can't say it any better, than this was stated already (from the greatest book of all time, the "tech manual for life" imo):

    "But by the grace of God I am what I am: and his grace which was bestowed upon me was not in vain; but I labored more abundantly than they all: yet not I, but the grace of God which was with me." - Corinthians Chapter 10, Verse 10

    (And, because I got LUCKY to have been exposed to some really GREAT classmates, professors, & colleagues on the job over time as well)

    ----

    "Delphi, VB You just disqualified yourself from "real" programming." -by clone53421 (1310749) on Tuesday August 24, @09:34AM (#33354120) Journal

    First of all, I code in well over 12 computer languages, and I also mentioned C/C++ which I do code in and have for over 15 yrs. now professionally (funny you conveniently omit that eh in your PARTIAL QUOTE of myself)... and, also?

    As far as Delphi??

    The designer of .NET and C# is Mr. Anders Heijelsberg at MS, and he is o

    1. Re:clone53421 using ac posts now? LMAO! by Anonymous Coward · · Score: 0

      You said a lot of bullshit designed to bury the fact that you don’t know jack shit about programming, but learned a few “catch phrases” that make you sound impressive. Meanwhile anybody who actually KNOWS HOW TO PROGRAM doesn’t need your “helpful” clarifications because clone’s post was completely sufficient to describe to anyone what needed to be done. Anyone who was too stupid to understand clone’s post is too stupid to be programming (and yes, that includes you... why am I not surprised that your shitware has been identified as malware? because stupid people who CAN’T PROGRAM can read a reference manual and call the right functions but that still doesn’t make their coding abilities any “good”).

      Apparently your favourite colour is “obtuse”.

  31. Clone the noob got pwned by Anonymous Coward · · Score: 0

    "You’re a moron. " - by Anonymous Coward on Thursday August 26, @03:03PM (#33384252)

    LOL, name calling the "best you got", there, 'batchfile boy'? Apparently so: Well, hate to clue you into this, but "new NEWS":

    Your ad hominem attacks and foaming at the mouth profane name tossing reactions only shows your "tell" and that you are upset at yourself mainly, not I, because you exposed yourself as a complete noob in coding because you didn't post that you have to use API calls to get to environment variables in languages like C/C++, VB, and Delphi.

    Funny how you also only used a partial quote of my words also when you only noted Delphi and VB, when I also posted C/C++ (I code fluently in over 12 languages since 1982).

    By the way/again: On Delphi? It knocked the crap out of MSVC++ in both math and strings speed as far back as 1997 and in VBPJ magazine no less, and still can today (D7 & below).

    So much for your "know-how" because you're only showing us it's non-existent or noob/rookie level.

    Posting as AC now too? LOL, who are you trying to fool here, noob?? It's not working.

    1. Re:Clone the noob got pwned by Anonymous Coward · · Score: 0

      I code fluently in over 12 languages since 1982

      Truly, you are amazing... I wasn't aware that so many dialects of bullshit even existed.

  32. All clone53421 has now is ad hominem attacks? by Anonymous Coward · · Score: 0

    See subject-line above, and clone53421's last fail post prooving my point.

    In addition to that? From another thread, you can see below where it is quoted, on how and where clone is also losing badly on C programming portability problems, where clone53421 is "on the ropes" as is his usual in failing badly, and it is where clone53421 has been asked to show he has done more noted accomplishments in the field of the computer sciences than apk has (apk has a dozen I know of, probably more, and clone53421? LOL, not a SINGLE ONE, all he has are his "ad hominem attacks" (jealous ones, lol, obviously)):

    "Reputable? LOL. More like a bunch of bullshit tech rags. A bunch of third-world publications and a "PCPitstop" magaznie that I'd put several large steps below even the "GeekSquad" in terms of technical expertise or source of quality computing advice... LOL." - by Anonymous Coward on Wednesday September 01, @04:10PM (#33440540)

    Windows IT Pro, Microsoft Tech Ed 2000-2002 as a finalist in its hardest category, and commercial software code to apk's credit, and NOTHING TO CLONE53421's CREDIT AS TO THE SAME, NOT EVEN A SINGLE ONE? LMAO... we all know the score here, and it's 12 to 0 in favor of apk (12) and clone53421 (0). Not even CLOSE.

    ----

    "Maybe a tiny step above "AntiVirus Pro 2010", BUT ONLY MAYBE. " - by Anonymous Coward on Wednesday September 01, @04:10PM (#33440540)

    Again: apk's just done far more than you have clone53421 and industry people liked his work where you? Nobody has, because you're a nobody... face it, facts are facts and you have none to your credit vs. apk with over a dozen by now, probably more too,

    Again, Windows IT Pro, Microsoft Tech Ed 2 yrs. in a row, and commercial software code to apk's credit seems to look good for apk. Clone53421 with nothing of the same to his name? LMAO, not so good for clone53421, especially after all of his (your) name tossing and ad hominem attacks.

    (I'd say you're just another jealous ne'er do well, clone53421, simply based on your reactions, lol, like a frustrated child with your profanities and name calling...)

    ----

    "I'm surprised you aren't embarrassed quoting them as sources. in fact, it's to clone53421's credit that shit like that hasn't been attributed to him." - by Anonymous Coward on Wednesday September 01, @04:10PM (#33440540)

    LOL, clone53421, who is you (as is your usual defending yourself with AC replies after you get shot down by others) doesn't have a damned thing to his credit, because he is a dime a dozen NE'ER DO WELL, period. Show us otherwise... lol, we KNOW you can't!

    ----

    "You're a joke and an embarrassment." - by Anonymous Coward on Wednesday September 01, @04:10PM (#33440540)

    If apk with a list of a dozen accomplishments in the eyes of reputable others is a joke and an embarrassement, then what are YOU, with NOTHING TO YOUR NAME WHATSOEVER, Clone53421?? LMAO... face it: You're a "ne'er do well" clone53421.

    ---

    "And we all know that THRONKA was YOU." - by Anonymous Coward on Wednesday September 01, @04:10PM (#33440540)

    Got proof of that, first of all? Otherwise, we know it's your typical ad hominem attack attempt and more libelous crap from you. Proof, from Clone53421?? LOL, of course not. Certainly not of better and more accomplishments than APK has in respected and reputable publications like Windows IT Pro, or MS' own TechEd!

    Clone53421, all you have is your desperate b.s., and you are free to write THRONKA, as he frequents the bbs where his comments are cited.

    Many others also have had the same results and querying "HOW TO SECURE Windows 2000/XP/Server 2003" online can show that many others liked APK's security guide so much, it is no small wonder he was paid to write it and won a tech contest for it in fact (unexpectedly in fact he said). Ha

  33. 12x in respected publications says otherwise by Anonymous Coward · · Score: 0

    See subject-line above, as well as the earlier posts here where clone53421 posts what a mere batchfile writer might do vs. what he ought to have indicated in the API calls needed to use environment strings in code like C, C++, Delphi, VB, or others, as well as clone53421's last fail post I have replied to now. It's all helping in my easily proving my point that clone53421 has been utterly smoked 3-4x now in technical topics in coding and in networking here, and is resorting to name calling and worse. Hilarious.

    In addition to that?

    From another thread with quotes below??

    Well, below you can see below where it is quoted, on how and where clone is also losing badly on C programming portability problems, where clone53421 is "on the ropes" as is his usual in failing badly, and it is where clone53421 has been asked to show he has done more noted accomplishments in the field of the computer sciences than apk has and clone53421 has ZERO, by way of comparison, lol!

    (apk has a dozen I know of, probably more, and clone53421? LOL, not a SINGLE ONE, all he has are his "ad hominem attacks" (jealous ones, lol, obviously)):

    "Reputable? LOL. More like a bunch of bullshit tech rags. A bunch of third-world publications and a "PCPitstop" magaznie that I'd put several large steps below even the "GeekSquad" in terms of technical expertise or source of quality computing advice... LOL." - by Anonymous Coward on Wednesday September 01, @04:10PM (#33440540)

    Windows IT Pro, Microsoft Tech Ed 2000-2002 as a finalist in its hardest category, and commercial software code to apk's credit, and NOTHING TO CLONE53421's CREDIT AS TO THE SAME, NOT EVEN A SINGLE ONE? LMAO... we all know the score here, and it's 12 to 0 in favor of apk (12) and clone53421 (0). Not even CLOSE.

    ----

    "Maybe a tiny step above "AntiVirus Pro 2010", BUT ONLY MAYBE. " - by Anonymous Coward on Wednesday September 01, @04:10PM (#33440540)

    Again: apk's just done far more than you have clone53421 and industry people liked his work where you? Nobody has, because you're a nobody... face it, facts are facts and you have none to your credit vs. apk with over a dozen by now, probably more too,

    Again, Windows IT Pro, Microsoft Tech Ed 2 yrs. in a row, and commercial software code to apk's credit seems to look good for apk. Clone53421 with nothing of the same to his name? LMAO, not so good for clone53421, especially after all of his (your) name tossing and ad hominem attacks.

    (I'd say you're just another jealous ne'er do well, clone53421, simply based on your reactions, lol, like a frustrated child with your profanities and name calling...)

    ----

    "I'm surprised you aren't embarrassed quoting them as sources. in fact, it's to clone53421's credit that shit like that hasn't been attributed to him." - by Anonymous Coward on Wednesday September 01, @04:10PM (#33440540)

    LOL, clone53421, who is you (as is your usual defending yourself with AC replies after you get shot down by others) doesn't have a damned thing to his credit, because he is a dime a dozen NE'ER DO WELL, period. Show us otherwise... lol, we KNOW you can't!

    ----

    "You're a joke and an embarrassment." - by Anonymous Coward on Wednesday September 01, @04:10PM (#33440540)

    If apk with a list of a dozen accomplishments in the eyes of reputable others is a joke and an embarrassement, then what are YOU, with NOTHING TO YOUR NAME WHATSOEVER, Clone53421?? LMAO... face it: You're a "ne'er do well" clone53421.

    ---

    "And we all know that THRONKA was YOU." - by Anonymous Coward on Wednesday September 01, @04:10PM (#33440540)

    Got proof of that, first of all? Otherwise, we know it's your typical ad hominem attack attempt and more libelous crap from you. Proof, from Clone53421?? LOL, of course not. Certainly not of better and m