[Info-vax] SAMBA and Ransomeware

[johnwallace4 at yahoo.co.uk]

On Friday, 28 July 2017 18:16:37 UTC+1, seasoned_geek  wrote:
> On Monday, July 17, 2017 at 9:49:03 AM UTC-5, Stephen Hoffman wrote:
> 
> Hoff,
> 
> Sorry for taking snippets from multiple messages here, but was editing off-line due to flaky Internet. Please forgive if I pasted this in the wrong message thread as well. I had to be off-line for a while.
> 
> >That written, Microsoft has decided to follow your suggestions here,
> >but is doing so with Windows 10.   Not with Windows XP or older
> >releases.    We'll eventually learn how well the Windows 10 approach
> >works for Microsoft, for Microsoft partners and ISVs, and for end-users
> >of Windows, too.  How well this works from a technical approach, and
> >around corporate financial, marketing and partnerships?  Even if
> >software compatibility continues, some new features are inevitably
> >going to exclude older hardware, and which will force hardware
> >upgrades; older hardware is inevitably going to age out.
> 
> Odd this since Microsoft is in the process of abandoning Windows in reality, not name, and Google is in the process of abandoning Android. Microsoft has already issued EOL for Windows Mobile without announcing any replacement. Both Google and Cannonical are fast at work on their own forks of Fuschia. Both companies have chosen that platform as "the one OS to rule them all." Pieces of Ubuntu have already moved in under Windows 10. It will soon be a few Windows APIs on top of Ubuntu with a Microsoft looking desktop. This was one of the big pushes behind ".Net Anywhere" or ".Net Lite" or whatever it was called. Given the rousing success of Mono I don't hold much hope for Microsoft getting it to work on a non-Microsoft platform, hence the multi-year transition to Linux under the hood.
> 
> I haven't looked at the Fuschia code base, but, it is an off-shoot of another project. I don't know if that project fully jettisoned the Linux kernel or not. The Linux kernel has some serious legacy design flaws which are getting worse now that they are trying to utilize CUDA cores. I understand, back in the day compiling the video driver into the kernel made some sense. It no longer does. We can no longer count on some 90% of hardware providing a VGA address space at a specific address range. Automatic upgrades of the kernel for Nvidia users are currently problematic at least for the YABU distros. Hopefully Neon will be full Debian soon and a large part of the problem "might" go away. At least the Ubuntu don't test sh*t part will go away.
> 
> A full redesign of the Linux Kernel making it small and API, not pointer, driven with shelled APIs for future external specialized processors was/is long overdue. CUDA is not going to be the last. There already are a few low market CUDA competitors, but when you can get a 2Gig video card having 384 CUDA for under $50, that's a lot of market inertia for competitors to overcome. Yes those cores are specialized and can be morphed to do many things, but, the reality is this quad-core now has 388 cores of varying capabilities. From at least one perspective it is a desktop sized Connection Machine much like people at Fermi and a few other places were creating with cast off microvaxes back in the day. The next logical step is for cards to come with 4Gig of RAM and close to 1024 something more general than CUDA consuming low power card people drop into their desktops for massive crunching/big data capabilities. The small form factor desktop or even fuller sized ATX mobo now becomes a backplane other computing capabilities get stuck into.
> 
> In short, what's old is new again and the Linux kernel was in no shape to handle it. The current ham-fisted CUDA stuff is proof of that. Even my friend who from time to time works with Linus himself readily admits that. He's just not quite ready to get a new baby and bath water.
> 
> 
> >
> >
> > Again: we can live in and can desire and seek Y2K-era security and
> > long-term server stability and the rest of the uptime era, or we can
> > deal with the environment we have now, with the need to deploy patches
> > more quickly, and prepare for the environment we're clearly headed
> > toward.   Wrist watches commonly have more capacity and more
> > performance than most of the VAX servers.   For those folks here that
> > are fond of disparaging or ranting about Microsoft or other vendors,
> > please do look at what they're doing, what they have available now, and
> > what they're working on.  Microsoft and Linux and other choices are far
> > more competitive than they once were, far more secure, and are far
> > ahead of OpenVMS in various areas.   The sorts of areas that show up on
> > RFPs and bid requests, too.   Times and requirements and environments
> > all change.   We either change, or we and our apps and our servers
> > retire in place.
> >
> 
> 
> I hear what you are saying, but firmly believe it is based on a false premise. Long ago, before VMS got an "Open" pre-pended by the sales resistance force, disgusting low life cretins paid lots of money to even lower forms of biological life, namely The Gartern Group and what became Accenture, to market a false statement:
> 
> <b>Proprietary bad, OpenSource good.</b>
> 
> This was a completely false statement. It was massive spin on the reality "Proprietary expensive, OpenSource cheap" and it completely overlooked the real definition of "cheap" there. North Korean knock-off sold at Walmart cheap, not high quality at low cost.
> 
> This "Proprietary bad, OpenSource good" mantra got beat into people's brains so much they believe it is true today. It's not.
> 
> Where is it written that every business system must connect directly to the Internet?
> 
> Where is it written that your core critical cluster must use TCP/IP?
> 
> Where is it written that external XML messages must feed directly from the Internet into a server which is directly connected to a critical database?
> 
> Where is it written the exact same CPU with the exact same BIOS/UEFI with the exact same cheap hard drive containing programmable firmware as the nearly worthless desktop must run your critical systems?
> 
> These are __all__ dramatic system architecture failures of biblical proportions. By moving to an x86 platform OpenVMS is now placing itself in the same position other worthless platforms now are in. Processor level binary code which can execute independent of OS can now penetrate OpenVMS infecting the BIOS/UEFI and commodity drive firmware. The OpenSource code gives hackers who've never seen anything other than a PC the way to penetrate and trigger its execution. Firmware viruses are the new frontier for both mafia and clandestine types.
> 
> https://www.kaspersky.com/blog/equation-hdd-malware/7623/
> 
> While we know about the hard drive firmware virus, people have been rather quiet about the BIOS/UEFI (whichever term you prefer) viruses. VMS never had this exposure and there is no method of defense when connected to the Internet or allowing TCP/IP on the box.
> 
> Even casually secure businesses never use XML or any other free-form messaging format internally. Externally, yes. They place some sacrificial Websphere or other message manipulator outside to be abused, but it can only pass back in fixed width proprietary formatted messages and it __never__ has access to a database it doesn't own. Doesn't matter if someone managed to force 2 billion characters into that first name tag trying to send in an SQL injection attack or some other nasty via an overflow crash. The first N characters are all that get dropped into the internal message and the rest are thrown away. Yes, you can get some garbage data, but you cannot be penetrated. Yes, I see many systems set up by complete and total idiots which grew up in the Microsoft sh*t design world but that doesn't mean real systems on real computers have to do stupid things.
> 
> Laugh all you want, I've been told of production systems which have some sacrificial Internet connected device which gets all kinds of messages from the outside world in Unicode, chunks out what it wants and morphs the data into EBCDIC and sends the data to big blue boxes via old proprietary IBM network protocols.
> 
> Of course, the most secure designs are fully air gapped. On a periodic basis they sneakernet removable media containing only data files over to the real machines.
> 
> Odd that. In today's mindlessly connected world, sneakernet is still the ultimate in system security.

Where is it written that there no difference between 
Open Source (e.g. Linux) and Open Standards (e.g. POSIX)?