Wandering Thoughts archives

2016-11-17

Link: Twice the bits, twice the trouble: vulnerabilities induced by migrating to 64-bit platforms

Adrian Colyer's Twice the bits, twice the trouble: vulnerabilities induced by migrating to 64-bit platforms (via) is a very readable and very interesting summary of an ultimately depressing academic paper on the security vulnerabilities that get induced in C code simply by migrating from 32-bit platforms to 64-bit platforms.

In theory I sort of knew about all of this, but it's one thing to vaguely have heard about it and another thing to see handy comparison charts and examples and so on of how relatively innocent C code introduces real vulnerabilities simply when you rebuild it on 64-bit machines and then expose it to attackers.

Here's a depressing quote from the academic paper to finish up with and motivate reading at least Colyer's summary of the whole thing:

Finally, we make use of this systematization and the experience thus gained to uncover 6 previously unknown vulnerabilities in popular software projects, such as the Linux kernel, Chromium, the Boost C++ Libraries and the compression libraries libarchive and zlibā€”all of which have emerged from the migration from 32-bit to 64-bit platforms.

That's, well, unfortunate. But not unexpected, I suppose. Maybe all future languages should not have any limited-range numeric types that can have different sizes on different platforms, even if it's theoretically an attractive idea for 'optimization'.

(I don't know what Rust does here, but Go does have int and uint, which are either 32 or 64 bits depending on the platform.)

links/C64BitMigrationVulnerabilities written at 14:01:52; Add Comment

The somewhat odd subject of Django versus Python

I was recently talking on Twitter with someone who was considering doing their website in Django as a learning project, because they really like Python. I had some tangled reactions to this and today I want to write them down in a better format than Twitter.

Simplified, I feel that basic use of Django is fairly detached from any particularly deep immersion into Python as a programming language in its own right. You certainly will write some Python as part of creating a basic Django web app, but you'll also write a bunch of Django specific things (including Django templates and other things that are not really connected to Python code). And some of Django's magic things cut directly against how Python normally works. The more basic the web app you have, the more easily it can probably be implemented using Django's standard basic features and thus the less Python you'll write.

Or in short, basic use of Django is more about Django than about Python. Only once you get beyond basic CRUD features and into complex application logic and so on do I think you're going to wind up immersed in Python itself, with Django simply acting as the scaffolding to connect it to the web.

It follows that the more you use Django features like the admin interface, the less Python immersion you're getting. If all goes well the admin interface can save you a lot of work writing update and modification forms and processing of them, but at least some of that would be actual Python code that the admin interface is 'saving' you from having to write.

I don't think this is specific to Django. Instead I expect it to be the same for any complex framework, because the purpose of a framework is to do the standard necessary work for you. This is a feature if you want a web app (especially with polished underlying code), but a drawback if you want to write Python. If your real desire is to write Python and wind up with a website, perhaps the right thing is a more minimal framework (although I don't know which one of them you want these days and all of my references are several years old by now).

(Unless you really want the experience, I don't think it makes much sense to go lower than a framework. It can be quite interesting and it'll give you a good appreciation for the underlying technologies involved, but it's probably going to take you rather a lot of time and work to wind up with a reasonably full-featured website. And if you want to develop a deeper understanding of the modern web environment, you probably want to focus more on Javascript in the browser anyways; my grumblings aside, that's where much of the real action is these days.)

PS: If you're doing anything really security sensitive, please do not roll your own code no matter how much you like writing Python. Use well-tested, well-audited, well-maintained framework code that gets a lot of exposure so that people will find (and fix) the remaining security bugs. It's really easy to have clever security ideas that aren't, or to miss some subtle issue.

python/DjangoVsPython written at 00:39:17; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.