Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


XPPOS2009

Member
  • Content Count

    11
  • Donations

    $0.00 
  • Joined

  • Last visited

Community Reputation

4 Neutral

About XPPOS2009

Profile Information

  • OS
    XP Pro x86
  • Country

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yes - all vulnerabilities exist regardless of whether or not they are exploited. Disabling RDS doesnt patch the code (remove the vulnerability) - the insecure code is still there, just not active: as soon as RDS is enabled, the (unpatched) vulnerability can be exploited. There is a significant distinction between vulnerabilities and exploits - vulnerabilities are actual defects (bad code/code design) in the software (Window's RDP/RDS implementation) - exploits are the specific tools/processes that use the vulnerabilities for effect (DoS, privilege escalation, remote access, etc). The article you cited ambiguously references this distinction - the exploit tool ("the most common version of wannacry") was coded/designed in a way that that was mostly ineffective against XP remotely (locally it was just as effective). In other (specific) words, XP had the same SMB code vulnerability(ies) as later versions of Windows , but the specific implementation of EternalBlue via the most common WannaCry code was, ironically, buggy and defective relative to XP's SMB implemention, and thus was relatively ineffective (especially when executed remotely). This might have even been "intentional", since at the time of WannaCry XP's market share was in the single digits and the code may have been optimized for 7/8/10/2008/2012 (covering more than 90% of Windows installs). Buggy/flawed/defective exploit code is just as common as buggy/flawed/defective vulnerability code and often serves as a limiting factor in the propagation and spread of malware - going back as far as malware has existed, long prior to the existence of networks or the internet. In fact almost every "internet worm" of note was/has been vastly limited in its propagation and damage due to this often un/der-reported "buggy malware" fact. Malware/exploit authors are just as (if not more so) prone to write/design buggy/flawed/defective code as the original target code authors - and we can be thankful for that. Just imagine if malware authoring was an industry where highly efficient/effective exploit coding services were up for bidding by corporations, governments, criminal syndicates...oh..wait..never mind.
  2. FYI - minor point/issue, but the included INFO.TXT file still retains/indicates version 1.6
  3. KB4487085 has been re-released (V2): http://download.windowsupdate.com/d/msdownload/update/software/secu/2019/02/windowsxp-kb4487085-v2-x86-embedded-enu_667f051ffe98ff99495e9b6ede2b8c321aba1ca3.exe Also available via AU/WU/MU (clears it if previously hidden as per usual) Package files are correctly platformed and versioned now - tested fine
  4. For whatever reason, I've had a few XP FF 52.x ESR installs that wouldnt download/install the Adobe Primetime Content Decryption Module unless/until I added: media.gmp-eme-adobe.forceSupported = true
  5. Anyone else getting KB4012864 again from AU suddenly today as of the last hour or so? It's appearing for all my XP WEPOS2009 installs. And its disappearing as soon as I start a manual scan at MU/WU. Interesting EDIT: Plot thickens - its installing in the background from AU for all of them, shows in MU/WU history. Question is, why is KB4012864 redownloading and automatically reinstalling with zero user intervention? Is this a "v2" that covers some additional found vulnerability? Or just a classic MU/WU/AU patch detection screwup? EDIT again: I incorrectly saw this as KB4012854 scanning the installed updates history. This is an entirely new update. This is merely a time zone update for Russian/Mongolia/Cypress etc. Must have been a last minute change and delayed release to AU/MU/WU since its clearly listed at the catalog on 3/16. FINAL EDIT: This is not the first time MS pushed an out-of-band time zone update through AU/MU/WU as a critical update with little to no warning that auto-installs and leaves little to no evidence of itself unless you happen to catch it at the time of download/installation or otherwise scan the updates installation history.
  6. I've been updating Silverlight for XP for a couple years now by downloading the latest Silverlight.exe offered whenever Silverlight gets security updated - it installs just fine on XP. https://www.microsoft.com/en-us/download/details.aspx?id=54857 And then you have 5.1.50905
  7. Doesn't work with Office 2007 installed etc. Just have to wait it out or manually download and install each update.
  8. Perhaps just install the update for it that does in fact, exist? https://www.catalog.update.microsoft.com/ScopedViewInline.aspx?updateid=43db2dfd-c320-436a-94bf-5f094498fe68
  9. Finally got all the remaining Office 2007 updates installed after about an 8 hour scan yesterday afternoon-evening. However, those PCs with Office 2007 "scan forever" problems, also experienced the continuous-reinstall problem with the .NET 4 update (KB2487367). Uninstalling all versions of .NET 4.x (Client/Extended) and reinstalling through MU, choosing all XP .NET updates first, and then all POS .NET updates afterwards, resulted in a "fixed" scenario.
  10. Just for snicks and giggles, i manually installed all of the XP updates for this month on two of the aforementioned XP+Office 2007-WEPOS mod+Microsoft Update configured (these are the worst/slowest when checking) PCs - "forever updating" still continues when AU and/or MU is enabled/used. Makes no difference whatsoever. Still chugging along in svchost.exe CPU-cycle bogland "endlessly"... I think whats happened is an extension/variation of the problem that afflicted XP a few years ago and Vista/7 more recently, but for Office products - they need to prune the Office Update patch tree, especially in relation to XP. Office 2007 tends to get as many/more updates as/than XP itself in a given month, and has for a while, and i think this is causing the more recent (laqst few months) super long forever extended recursive registry botched checking svchost.exe CPU hogging. A good test of this theory would be switching back to Windows Update (from Microsoft Update) on those XP+2007 PCs and seeing if it continues. If i have time, i may test this later.
  11. This hasnt worked for me on several XP PCs with Office 2003/2007 - they continue to have "forever updating" with 25/50/100% CPU usage (depending on HT/corte availability) even after installing the latest Cumulative IE monthly patch. They simply have to be left alone for a day or three until they finish checking/downloading and the systray M/W/A Update icon appears...then....most of the time..the updates install and things normalize for a month.... This has been going on for 4 months or so now (I could manually download/install all the relevant updates..but its not worth the time/avoids the experiential data gathering).
×
×
  • Create New...