Computing – Page 20 – More Zonkyness

Ubuntu, Compiling Awesome, and Messing With Lua

Computing, Linux, Working Notes No Responses »

May 202017

I just love messing around with run-time languages that I know relatively little about (and if your sarcasm detector isn’t flashing red about now, take it out and give it a good talking to).

The problem detailed here is something that you are unlikely to encounter unless you get into weird stuff like running an odd-ball window manager, aren’t content with the version of said window manager distributed with your Linux distribution, and are used to re-compiling things from scratch.

It all started when I upgraded Ubuntu on my work machine (to Zesty Zapus). The window manager version was upgraded from 3.5 to 4.0, which broke on my configuration file (3.5); not a big problem I thought, as I had already upgraded my window manager at home to 4.1 and reconfigured the configuration file. I copied the updated configuration file from home into place.

And it failed. Apparently I use 4.1-isms within the file. As I was not happy about tinkering with the file to downgrade it (in a language I know relatively little about), I decided to re-compile Awesome 4.1 instead.

Which failed with a weird error :-

» awesome --version
awesome v4.1 (Technologic)
 • Compiled against Lua 5.3.3 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.4
 • LGI version: [string "return require('lgi.version')"]:1: module 'lgi.version' not found:
	no field package.preload['lgi.version']
	no file '/usr/local/share/lua/5.3/lgi/version.lua'
	no file '/usr/local/share/lua/5.2/lgi/version.lua'
	no file '/usr/local/share/lua/5.3/lgi/version/init.lua'
	no file '/usr/local/share/lua/5.2/lgi/version/init.lua'
	no file '/usr/local/lib/lua/5.3/lgi/version.lua'
	no file '/usr/local/lib/lua/5.3/lgi/version/init.lua'
	no file '/usr/share/lua/5.3/lgi/version.lua'
	no file '/usr/share/lua/5.3/lgi/version/init.lua'
	no file './lgi/version.lua'
	no file './lgi/version/init.lua'
	no file '/usr/local/lib/lua/5.3/lgi/version.so'
	no file '/usr/lib/x86_64-linux-gnu/lua/5.3/lgi/version.so'
	no file '/usr/lib/lua/5.3/lgi/version.so'
	no file '/usr/local/lib/lua/5.3/loadall.so'
	no file './lgi/version.so'
	no file '/usr/local/lib/lua/5.3/lgi.so'
	no file '/usr/lib/x86_64-linux-gnu/lua/5.3/lgi.so'
	no file '/usr/lib/lua/5.3/lgi.so'
	no file '/usr/local/lib/lua/5.3/loadall.so'
	no file './lgi.so'

Which had me stumped for a while, and it turns out that DuckDuckGo didn’t have an obvious fix (one of the reasons for writing this).

Eventually I figured out that awesome was not finding the LGI module (I can be slow at times) which was odd because it was definitely installed. However it turns out that it was installed in /usr/share/lua/5.2/lgi. So despite having lua 5.3 installed, extra lua modules can only be seen if you have lua 5.2 installed?

The “fix” for this was to create an environment variable telling LUA to search for files in rather more places before starting Awesome :-

export LUA_PATH="/usr/local/share/lua/5.3/?.lua;/usr/local/share/lua/5.2/?.lua;/usr/local/share/lua/5.3/?/init.lua;/usr/local/share/lua/5.2/?/init.lua;/usr/local/lib/lua/5.3/?.lua;/usr/local/lib/lua/5.3/?/init.lua;/usr/share/lua/5.3/?.lua;/usr/share/lua/5.2/?.lua;/usr/share/lua/5.3/?/init.lua;/usr/share/lua/5.2/?/init.lua;./?.lua;./?/init.lua"

This was created by running lua from the command line and running print(package.path) to display the default setting, and adding the 5.2 equivalent for many elements.

As to whether it works or not, well I cannot be sure (I’m not going into work on a weekend just to check if the window manager fires up), but Awesome itself seems happy with the result :-

» awesome --version
awesome v4.1 (Technologic)
 • Compiled against Lua 5.3.3 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.4
 • LGI version: 0.9.1

So it can find LGI, but whether it can do anything useful with it remains to be seen!

WannaCrypt Makes Other Malware Authors WannaCry

Computing, Security No Responses »

May 172017

It may not be very funny, but the funny thing about WannaCrypt is that it is somewhat of a failure! Unless the authors are spectacularly stupid (not entirely impossible incidentally), they have no way to recover their ill-gotten gains. The pile of looted bitcoins they have acquired is fully visible, so any attempt to use those coins will almost certainly result in them being tracked down – they have attracted too much attention.

Which is another aspect of the WannCrypt malware – it has highlighted the vulnerability (MS17-010) and caused a huge vulnerability hunt. Which is causing those who wrote other malware (such as Adylkuzz) to gnash their teeth, because otherwise their malware would have quietly worked away in the background. The malware authors behind Adylkuzz have probably made more money than the WannaCrypt malware authors … and may well get away with their loot too.

Which is why other malware authors “wannacry” – the attention that WannaCrypt has gotten has ruined MS17-010 for them.

When Windows Update Lies

Computing, Security No Responses »

May 172017

It seems rather strange when you discover it, but Windows Update sometimes lies about what updates have been installed. I am not sure how often this happens, but it does happen from time to time. Which with WannaCrypt rampaging around is somewhat unfortunate.

What seems to happen is that Windows Update gets confused about what patches it has installed – it’s internal database gets corrupt. One possible fix for this is to remove the database :-

net stop wuauserv
cd %systemroot%
ren SoftwareDistribution SoftwareDistribution.old
net start wuauserv
rd /s/q SoftwareDistribution.old

When using Windows 10, you may well have to start (net start wuauserv) Windows Update services before stopping them. Once you have removed the directory, the next time you run Windows Update in the gooey, it will spend some time rebuilding it’s database and hopefully will then pick up the missing updates. No promises but this worked on at least one server that had unacknowledged missing patches.

Of course without a proper vulnerability scanner it may be tricky to determine when Windows is lying about being fully patched. The best bet is to assume it is lying whenever something like WannaCrypt comes along.

The other possibility is to look into something like Autopatcher which is intended for offline updates – you can download the Microsoft updates and use the tool to patch Windows computers from the downloads.

VirtualBox, Windows Guest Virtual Machines, and The VirtIO Network Interface

Computing, Working Notes No Responses »

Apr 302017

Despite how long I have been running Windows in virtual machines (as far back as Vmware Workstation 1.0), I have never gotten around to looking at the virtio network interface – except for naïvely turning it on once, finding it didn’t work, and turning it off – so I decided to have a look at it. I was prompted to do this by a suggestion that emulating the NIC hardware as opposed to simply using a virtual communications channel to the host would hurt network performance. Good job I chose a long weekend because I ran into a few issues :-

Getting appropriate test tools took a while because most of the tools I know of are very old; I ended up using iperf2 on both the Linux main host and the Windows 10 guest (within the “Windows
The “stable” virtio drivers (also called “NetKVM”) drivers didn’t work. Specifically they could send packets but not receive them (judging from the DORA conversation that was more of a DODO). I installed the “latest” drivers from https://fedoraproject.org/wiki/Windows_Virtio_Drivers. Note to late readers: this was as of 2017-04-30; different versions may offer different results.
Upgrading my ancient Debian Jessie kernel to 4.9 on the off-chance it was a kernel bug turned into a bit of an exercise what with ZFS disappearing after the upgrade, and sorting out the package dependencies to get it re-installed was “interesting” (for small values of course). No data loss though.

I ran two tests :-

sudo nping –tcp -p 445 –count 200 –data-len 1280 ${ip of windows guest) – to judge how reliable the network connection was.
On the Linux host: sudo iperf -p 50001
On the Windows guest (from within the Ubuntu-based environment): sudo iperf -p 50001 -c ${ip of Linux host}

Device	nping result	iperf result
Windows guest (virtual Intel Pro 1000 MT Desktop	1 lost	416 Mbits/sec
Windows guest (virtio)	0 lost	164 Mbits/sec
CuBox running ARM Linux	n/a	425 Mbits/sec

Which is not the result I was expecting. And yes I did repeat the tests a number of times (I’ve cheated and chosen the best numbers for the above table), and no I did not confuse which NIC was configured at the time of the tests nor did I get the tests mixed up. And to those who claim that the use of the Ubuntu environment screwed things up, that appears not to be the case – I repeated the test with a Windows compiled version of iperf with much the same results.

So it seems despite common sense indicating that a NIC “hardware” custom designed for a virtual environment should perform better than an emulation of a hardware NIC, the actual result in this case was the other way around. Except for the nping result which shows the loss of a single packet with the emulated hardware NIC.

Unicode Passwords?

Computing, Security No Responses »

Apr 062017

One of the possibilities when setting a password is to use non-ASCII characters, such as ¨þ¨ (that is a thorn). Well perhaps something a little more secure than just a single character.

But just how sensible is it?

The first thing to bear in mind is that you need to be able to enter the password reliably in all circumstances. A tale from the mists of time: I once set a root password on a Unix machine that included the ¨@¨ character, which normally worked fine but failed on the system console because on that terminal the old Unix tty was still active and ¨@¨ would erase a line, making it impossible to enter the password.

Fortunately I realised what the problem was before it became more than a little annoying.

But the point still remains – if you cannot type a password, you cannot authenticate. So for passwords such as firmware passwords, system encryption passwords, or normal computer account passwords, a password containing Unicode characters is probably a very bad idea.

But for when you have full control over your computer(s), such as for web account passwords, a password containing Unicode characters is worth considering.

So how safe is a password containing a Unicode character anyway? Well, on my usual password cracking machine, john the ripper is unable to crack the password ¨þ¨ in approximately 24 hours. Of course that is a bit of a cheat as john the ripper does not by default check Unicode characters, and if it did it would be able to crack a one character password. But it would take longer; adding Unicode characters increases the space that john the ripper needs to search in order to find your password.

And perhaps more importantly makes it less likely for a password guesser (Hydra for example) to be successful.

So if you normally use a password such as thistlethinthorn, changing it to þistleþinþorn is worth considering. Or indeed changing the separator between words in a multiword password to a Unicode character: thistle☠thin☠thorn, or red¡whistle¡wheel.

Older Entries Newer Entries