The latest Nokia, the Nokia Lumia.

Lumia in Spanish means Prostitute.

That is all.

Its fairly easy to find out what brand of processor and its speed on OS X with About This Mac, however finding out the model number has always been frustrating for some people, who perhaps want to upgrade their RAM, or see how old their processor is.

Its fairly easy to find out, fire up Terminal and type this

sysctl -n machdep.cpu.brand_string

And theres your processor model given right to you, it should look something similar to.

Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz

Then copy and paste the model number (in this case i5-2520M) into Google search, and usually the first link contains all you need to know.

It isn’t market share, primarily.

This is quoted from somewhere, I couldn’t find the source, let me know if you know where it came from and ill happily mention it

 1) Until Vista, the admin account in Windows did not implement DAC in a way to prevent malware by default. Also, Windows has a far greater number of privilege escalation vulnerabilities that allow bypassing DAC restrictions even if DAC is enabled in Windows.

Much of the ability to turn these vulnerabilities into exploits is due to the insecurity of the Windows registry. Also, more easily being able to link remote exploits to local privilege escalation exploits in Windows is due to the Windows registry.

Mac OS X does not use an exposed monolithic structure, such as the Windows registry, to store system settings. Also, exposed configuration files in OS X do not exert as much influence over associated processes as the registry does in Windows.

Mac OS X Snow Leopard has contained only 3 elevation of privilege vulnerabilities since it was released; obviously, neither of these were used in malware. Lion has contained 2 so far but one of these vulnerabilities doesn’t affect all account types because of being due to a permissions error rather than code vulnerability.

The following link shows the number of privilege escalation vulnerabilities in Windows 7 related to just win32k:

http://cve.mitre.org/cgi-bin/cvekey….yword=win32k+7

More information about privilege escalation in Windows 7:

http://www.exploit-db.com/bypassing-…vista7-mirror/ -> guide to develop exploits to bypass UAC by manipulating registry entries for kernel mode driver vulnerabilities.

https://media.blackhat.com/bh-dc-11/…nelpool-wp.pdf -> more complete documentation about Windows kernel exploitation.

http://mista.nu/research/mandt-win32k-paper.pdf -> more complete documentation about alternative methods to exploit the Windows kernel.

http://threatpost.com/en_us/blogs/td…net-bug-120710 -> article about the TDL-4 botnet which uses a UAC bypass exploit when infecting Windows 7.

2) Windows has the potential to have full ASLR but most software does not fully implement the feature. Most software in Windows has some DLLs (dynamic link libraries = Windows equivalent to dyld) which are not randomized.

http://secunia.com/gfx/pdf/DEP_ASLR_2010_paper.pdf -> article overviewing the issues with ASLR and DEP implementation in Windows.

Also, methods have been found to bypass ASLR in Windows 7.

http://vreugdenhilresearch.nl/Pwn2Ow…tExplorer8.pdf -> article describing bypassing ASLR in Windows 7.

Mac OS X has full ASLR implemented on par with Linux. This includes ASLR with position independent executables (PIE). DLLs in Windows have to be pre-mapped at fixed addresses to avoid conflicts so full PIE is not possible with ASLR in Windows.

Using Linux distros with similar runtime security mitigations as Lion for a model, client-side exploitation is incredibly difficult without some pre-established local access. Of course, this is self defeating if the goal of the exploitation is to achieve that local access in the first place.

See the paper linked below about bypassing the runtime security mitigations in Linux for more details.

http://www.blackhat.com/presentation…slr-slides.pdf

The author only manages to do so while already having local access to the OS.

3) Mac OS X Lion has DEP on stack and heap for both 64-bit and 32-bit processes. Third party software that is 32-bit may lack this feature until recompiled in Xcode 4 within Lion. Not much software for OS X is still 32-bit.

But, not all software in Windows uses DEP; this includes 64-bit software. See first article linked in #2.

4) Mac OS X implements canaries using ProPolice, the same mitigation used in Linux. ProPolice is considered the most thorough implementation of canaries. It is known to be much more effective than the similar system used in Windows.

http://www.blackhat.com/presentation…rman-paper.pdf -> article comparing ProPolice to stack canary implementation in Windows.

5) Application sandboxing and mandatory access controls (MAC) in OS X are the same thing. More specifically, applications are sandboxed in OS X via MAC. Mac OS X uses the TrustedBSD MAC framework, which is a derivative of MAC from SE-Linux. This system is mandatory because it does not rely on inherited permissions. Both mandatorily exposed services (mDNSresponder, netbios…) and many client-side apps (Safari, Preview, TextEdit…) are sandboxed in Lion.

Windows does not have MAC. The system that provides sandboxing in Windows, called mandatory integrity controls (MIC), does not function like MAC because it is not actually mandatory. MIC functions based on inherited permissions so it is essentially an extension of DAC (see #1). If UAC is set with less restrictions or disabled in Windows, then MIC has less restrictions or is disabled.

http://www.exploit-db.com/download_pdf/16031 -> article about Mac sandbox.

http://msdn.microsoft.com/en-us/libr…(v=VS.85).aspx -> MS documentation about MIC.

https://media.blackhat.com/bh-eu-11/…xes-Slides.pdf -> researchers have found the MIC in IE is not a security boundary.

6) In relation to DAC and interprocess sandboxing in OS X in comparison with some functionality of MIC in Windows 7 (see #5), the XNU kernel used in OS X has always had more secure interprocess communication (IPC) since the initial release of OS X. 

Mac OS X, via being based on Mach and BSD (UNIX foundation), facilitates IPC using mach messages secured using port rights that implement a measure of access controls on that communication. These access controls applied to IPC make it more difficult to migrate injected code from one process to another.

Adding difficulty to transporting injected code across processes reduces the likelihood of linking remote exploits to local exploits to achieve system level access.

As of OS X Lion, the XPC service has also been added to implement MAC (see #5) on IPC in OS X. (http://developer.apple.com/library/m…CServices.html)

7) Windows has far more public and/or unpatched vulnerabilities than OS X.

http://www.vupen.com/english/zerodays/ -> list of public 0days.

http://www.eeye.com/Resources/Securi…ro-Day-Tracker -> another list of public 0days. (Most if not all of the Apple vulnerabilities in this list were patched in the latest Apple security update ->http://support.apple.com/kb/HT5002)

http://m.prnewswire.com/news-release…110606584.html -> article about 18 year old UAC bypass vulnerability.

8) Password handling in OS X is much more secure than Windows.

The default account created in Windows does not require a password. The protected storage API in Windows incorporates the users password into the encryption key for items located in protected storage. If no password is set, then the encryption algorithm used is not as strong. Also, no access controls are applied to items within protected storage.

In Mac OS X, the system prompts the user to define a password at setup. This password is incorporated into the encryption keys for items stored in keychain. Access controls are implemented for items within keychain.

Also, Mac OS X Lion uses a salted SHA512 hash, which is still considered cryptographically secure. It is more robust than the MD4 NTLMv2 hash used to store passwords in Windows 7.

http://www.windowsecurity.com/articl…ord-Part1.html -> article about Windows password hashing.

9) The new runtime security mitigation improvements to be included in Windows 8 have already been defeated.

http://vulnfactory.org/blog/2011/09/…op-mitigation/

To put this into perspective, methods to bypass the new runtime security mitigations in Mac OS X Lion are not yet available.

I’ve been using an Android and iPhone at same time for a bit now, ill post a review here when I get time.

In the last few weeks, Ive been receiving perhaps 100 spam comments a day on this blog, and I would actually like to make it automatic approval of comments, I love them.

I don’t know why some chinese spammer thinks I love Viagra? Really? I’m not that desperate.

I’ve changed Askimet so it now works (hopefully), and made all comments not require aprooval, happy commenting.

P.S If your the ass that put my blog in your script to post Viagra spam, go kill yourself.

Just a quick simple wizard of moving OpenVZ to another drive, since its stored in the plain folder of /vz

I presume you’ve already partitioned and formatted your drive (ext3 or ext4 works best), so we need to mount your new drive.

mkdir /vznew
mount /dev/<DRIVE IDENTIFIER HERE> /vznew (find identifier via fdisk
-l)

Now we need to turn off your OpenVZ VPSs and move the data, including -p to reserve permissions.

service vz stop
cp -Rvp /vz/* /vznew/

Now we need to disable the old /vz folder and mount the new one as /vz

mv /vz /vzold
umount /vznew
mkdir /vz 
mount /dev/<DRIVE IDENTIFIER HERE> /vz
service vz start

There you go, that should start all your OpenVZ VPSs from the new drive, you’re also need to tell the OS that you want it to mount that drive as /vz every time you boot.

You’re need to edit /etc/fstab and add this line,  remember to change the drive on the first part, and if your using a different drive format, change that too (ext3 etc)

/dev/sdc1        /vz                ext3    defaults        1 1

So you should end up something similar to

LABEL=/                 /                ext3    defaults        1 1
tmpfs                   /dev/shm         tmpfs   defaults        0 0
devpts                  /dev/pts         devpts  gid=5,mode=620  0 0
sysfs                   /sys             sysfs   defaults        0 0
proc                    /proc            proc    defaults        0 0
LABEL=SWAP-sda2         swap             swap    defaults        0 0
/dev/sdc1               /vz    	         ext3    defaults        1 1

You see many companies advertising that companies move their own setup email servers to their “Cloud”, but what are the advantages of this?

There are none, apart from you don’t manage the servers or pay the bandwidth, you pay someone else todo it for you. Infact theres no single difference from “Cloud” Email and Normal Email, however in so called “Cloud” email another company controls your data and manages it instead of you.

Cloud refers to anything on the internet, anything outside your router is considered “Cloud” if what these businesses market their products as truly cloud think their cloud.

In Lion, Apple dropped the FTP Server support, however they only removed the GUI.

You can enable it via the command line still, pretty easy actually. Apple have also dropped SystemStarter so you’re forced to use launchctl (which works better)

To start it

sudo -s
launchctl load -w /System/Library/LaunchDaemons/ftp.plist

To stop it

sudo -s
launchctl unload -w /System/Library/LaunchDaemons/ftp.plist

Hope that helps!

P.S, close the Terminal window open after you’ve finished, you don’t want to leave a root shell open.