Even before your secure coding... patch your server
Monday security report
Last week was quite busy in term of security issues. While people were still facing a security issue affecting Ruby on Rails applications and that was used to exploit github, a new serious vulnerability is the candidate to make pentester happy while assessing customers systems: the MS12-020 bullettin.
Microsoft MS12-020 bulletin
I know, you’re a good guy and you don’t expose RDP protocol on a Microsoft Windows based server over the Internet, but there are also I’m in rush, I have to deploy guys who make mistakes and who don’t take architectural security so seriously.
What about opensource?
Opensource software has security vulnerabilities as well, no one is perfect. Someone will argument that opensource maintainers are quickies to fix vulnerabilities compared to commercial vendors.
Most of times this is true, however when a project don’t have a strong community behind, it fails to have a well organized security response team.
NGINX memory corruption
Looking at the patch, it seems that the usage of ngx_cpystrn exposes the code to a off by one buffer overflow.
``` c nginx 1.0.14 memory corruption patch http://nginx.org/download/patch.2012.memory.txt … — src/http/modules/ngx_http_fastcgi_module.c +++ src/http/modules/ngx_http_fastcgi_module.c @@ -1501,10 +1501,10 @@ ngx_http_fastcgi_process_header(ngx_http h->lowcase_key = h->key.data + h->key.len + 1 + h->value.len + 1;
- ngx_cpystrn(h->key.data, r->header_name_start,
- h->key.len + 1);
- ngx_cpystrn(h->value.data, r->header_start,
- h->value.len + 1);
- ngx_memcpy(h->key.data, r->header_name_start, h->key.len);
- h->key.data[h->key.len] = ‘\0’;
- ngx_memcpy(h->value.data, r->header_start, h->value.len);
- h->value.data[h->value.len] = ‘\0’; } … ```
Advisory says that:
Without this fix contents of previously freed memory might be sent to a client if an upstream server returned specially crafted response, potentially resulting in sensitive information leak.
There is no magic bullet in application security. The important thing is that a server is a living object and that vulnerabilities appear almost everyday. When you expose a web application to your customers (it doesn’t matter if using Internet or an intranet) you must take care about system patching.
You don’t want to spend countless hours in safe coding, testing and code review and having all your system being exploited by an old school buffer overflow, do you?