A start to migrating the security stuff, it's mostly self explanatory but we'll need to document some of how this works
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/hugo/archetypes/cve.md Sat Jan 18 10:32:21 2020 -0600
@@ -0,0 +1,24 @@
+Explain the security bug. --- a/hugo/content/about/philosophy.md Thu Jan 16 22:38:56 2020 -0600
+++ b/hugo/content/about/philosophy.md Sat Jan 18 10:32:21 2020 -0600
@@ -1,6 +1,7 @@
title: Philosophy and Goals
date: 2019-08-22T03:45:43.000Z
lastmod: 2019-08-22T03:45:43.000Z
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/hugo/content/about/security/_index.md Sat Jan 18 10:32:21 2020 -0600
@@ -0,0 +1,65 @@
+Being a network client which interacts with untrusted users and servers, +managing vulnerabilities and security response is important to the Pidgin +project and to our users. We have established procedures for collecting +security-related information, and for disclosing this information to the +Please see our comprehensive +[list of known and reported security advisories](advisories/) for +information on past vulnerabilities. +## Reporting a Security-related Issue +If you believe you have discovered a security problem or vulnerability in +Pidgin, libpurple, finch, or one of our related projects, please let us know +by emailing [security@pidgin.im](mailto:security@pidgin.im). +In order to help us fix the problem as quickly as possible and with as little +exposure to malicious intent to our users as can be managed, we ask that you +give us a chance to fix the problem before you publish its existence or details +in a public forum, and that you provide us with as much information as you can. +In return, we will endeavor to respond to your concerns in a timely fashion. +When reporting a security-related bug or a vulnerability, please provide us +with as much of the information in the following list as possible. If you +don't know what something is or how to provide it, that's OK, leave it out and +tell us what you do know. +* A way to contact you or your organization. +* The version of Pidgin, libpurple, finch, or other package in which the + problem was discovered. +* A concise description of the problem, including a summary of why you believe + it is security-critical. This might be, for example, "Receipt of an invalid + XMPP message containing the tag `<foo>`; causes Pidgin to write data to an + invalid memory location." +* Steps to reproduce the problem, if known. +* Any debugging information, including backtraces (see our instructions for + [obtaining a backtrace](https://developer.pidgin.im/wiki/GetABacktrace), a + debug log (the output of pidgin -d), etc. +* Any proof of concept exploits, debugging tools, or other information you have + and are willing to divulge. +* The oldest and newest versions of our software affected by the bug *to the + best of your knowledge*. If you don't know, that's fine — we'll try to +* Information on any security reports or vulnerability assessments you may have + already made on the issue (preferably not yet public, as mentioned above). +* Any proposed embargo dates, release schedules, etc. you or your organization +## Receiving Security-related Reports +We maintain a list of packagers and maintainers of Pidgin and related software +which we notify of security vulnerabilities and their fixes prior to disclosure +to the public. This allows packagers and distributors of our software to +release patched or updated versions simultaneously with the public disclosure +of known issues. We attempt to provide sufficient advance warning to this list +that packages may be properly prepared before disclosure. +If you believe you should be on this list, please contact +[security@pidgin.im](mailto:security@pidgin.im) and let us know why. --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/hugo/content/about/security/advisories/_index.md Sat Jan 18 10:32:21 2020 -0600
@@ -0,0 +1,11 @@
+This page lists all potential security vulnerabilities discovered since August +1st, 2004 in Pidgin (or Gaim), Finch, libpurple, or any official plugins +included with those programs. --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/hugo/content/about/security/advisories/cve-2004-0500-00.md Sat Jan 18 10:32:21 2020 -0600
@@ -0,0 +1,24 @@
+date: 2004-08-22T00:00:00.000Z +cveNumber: cve-2004-0500 +summary: MSN strncpy buffer overflow +discoveredBy: Sebastian Krahmer, SUSE Security Team +In two places in the MSN protocol plugins (`object.c` and `slp.c`), `strncpy` +was used incorrectly; The size of the array was not checked before copying to +it. Both bugs affect MSN's MSNSLP protocol, which is peer-to-peer, so this +could potentially be easy to exploit. +Bounds checking was added in both places. --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/hugo/content/about/security/advisories/cve-2004-0754-00.md Sat Jan 18 10:32:21 2020 -0600
@@ -0,0 +1,33 @@
+date: 2004-08-26T00:00:00.000Z +cveNumber: cve-2004-0754 +summary: Groupware message receive integer overflow +discoveredBy: Sean ("infamous42md\") +Integer overflow in memory allocation results in heap overflow. By passing the +size variable as `~0`, integer overflows to 0 when 1 is added in `g_alloc()`. +A `malloc(0)` call results in 16 bytes of memory being allocated on IA- 32. +Then we can overflow the heap when `nm_read_all()` is called next step. +Usually cases like this suck for exploitation, because the len (`~0`) is so +large that a following call to `memcpy()` or `strcpy()` will just run into +kernel mem or unmapped address and fault. However in this case we read the +data from the network via a `read()` call, so we can just stop sending data and +close the connection to short out before `~0` bytes are read. However, this is +triggered by input from the server, not directly from a client. Someone +running a malicious groupware server could leverage this to run arbitrary code +Bounds checking was added. --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/hugo/content/about/security/advisories/cve-2004-0784-00.md Sat Jan 18 10:32:21 2020 -0600
@@ -0,0 +1,26 @@
+date: 2004-08-22T00:00:00.000Z +cveNumber: cve-2004-0784 +summary: Smiley theme installation lack of escaping +discoveredBy: A Gaim Crazy Patch Writer +To install a new smiley theme, a user can drag a tarball from a graphical file +manager, or a hypertext link to one from a web browser. When a tarball is +dragged, Gaim executes a shell command to untar it. However, it does not +escape the filename before sending it to the shell. Thus, a specially crafted +filename could execute arbitrary commands if the user could be convinced to +drag a file into the smiley theme selector. +Filenames are now escaped using `g_shell_quote()`. --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/hugo/content/about/security/advisories/cve-2004-0785-00.md Sat Jan 18 10:32:21 2020 -0600
@@ -0,0 +1,23 @@
+date: 2004-08-26T00:00:00.000Z +cveNumber: cve-2004-0785 +summary: URL decode buffer overflow +discoveredBy: Sean ("infamous42md") +Buffer overflow. The URL is decoded into a static buffer of length 2048 bytes. +I'm not sure it's possible to receive a URL longer than 2048 bytes, as many +protocols have message limits that are shorter than that. +A check to make sure the source string is shorter than 2048 bytes is performed. --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/hugo/content/about/security/advisories/cve-2004-0785-01.md Sat Jan 18 10:32:21 2020 -0600
@@ -0,0 +1,27 @@
+date: 2004-08-26T00:00:00.000Z +cveNumber: cve-2004-0785 +summary: Local hostname resolution buffer overflow +discoveredBy: Sean ("infamous42md") +Buffer overflow. If the local computers host name is not in /etc/hosts, and +the computer performs a DNS query to obtain it's hostname when signing on to +zephyr, it could receive a reply with a hostname greater than `MAXHOSTNAMELEN` +(generally 64 bytes). If `gethostbyname()` does not ensure the size of +`hostent->h_name` is less than `MAXHOSTNAMELEN`, this value would be copied to +a buffer that is not large enough. +The calls to copy the hostname were replaced with calls that check the length +of the destination buffer. --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/hugo/content/about/security/advisories/cve-2004-0785-02.md Sat Jan 18 10:32:21 2020 -0600
@@ -0,0 +1,22 @@
+date: 2004-08-26T00:00:00.000Z +cveNumber: cve-2004-0785 +summary: RTF message buffer overflow +discoveredBy: Sean ("infamous42md") +Buffer overflow. There are some loops that read into fixed-sized buffers and +do not check to make sure they are not writing too much. +Added bounds checking to the two loops. --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/hugo/content/about/security/advisories/cve-2016-2375-00.md Sat Jan 18 10:32:21 2020 -0600
@@ -0,0 +1,22 @@
+date: 2016-06-21T00:00:00.000Z +cveNumber: cve-2016-2375 +talosReportId: talos-2016-0143 +summary: Pidgin MXIT Suggested Contacts Memory Disclosure Vulnerability +discoveredBy: Yves Younan of Cisco Talos +A malicious server or man-in-the-middle could trigger a crash or disclosure of information from memory. +Validate the field and attribute counts. --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/hugo/content/about/security/advisories/cve-2017-2640-00.md Sat Jan 18 10:32:21 2020 -0600
@@ -0,0 +1,22 @@
+date: 2017-03-09T00:00:00.000Z +cveNumber: cve-2017-2640 +summary: Out-of-bounds write when stripping xml +discoveredBy: Joseph Bisch +An out-of-bounds write when invalid xml is sent by a malicious server. +Only decode HTML entities that are well formed. --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/hugo/content/about/security/advisories/independent-20040826-00.md Sat Jan 18 10:32:21 2020 -0600
@@ -0,0 +1,29 @@
+title: independent-20040826-00 +date: 2004-08-26T00:00:00.000Z +summary: Content-length DOS (malloc error) +discoveredBy: Sean ("infamous42md") +Remote crash. When a remote server provides a large `content-length` header +value, Gaim will attempt to allocate a buffer to store the content, however +this allocation attempt will cause Gaim to crash if the length exceeds the +amount of possible memory. This happens when reading profile information on +some protocols. It also happens when smiley themes are installed via drag and +The call to `g_malloc()` was replaced with a call to `g_try_malloc()`. If the +memory could not be allocated the function returns instead of causing the --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/hugo/content/about/security/advisories/independent-20041019-00.md Sat Jan 18 10:32:21 2020 -0600
@@ -0,0 +1,25 @@
+title: independent-20041019-00 +date: 2004-10-19T00:00:00.000Z +summary: MSN File transfer DOS (malloc error) +Remote crash. After accepting a file transfer request, Gaim will attempt to +allocate a buffer of a size equal to the entire filesize, this allocation +attempt will cause Gaim to crash if the size exceeds the amount of available +Don't allocate a buffer for file transfers. --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/hugo/content/about/security/advisories/independent-20041019-01.md Sat Jan 18 10:32:21 2020 -0600
@@ -0,0 +1,24 @@
+title: independent-20041019-01 +date: 2004-10-19T00:00:00.000Z +summary: MSN SLP DOS (malloc error) +Remote crash. Gaim allocates a buffer for the payload of each message received +based on the size field in the header of the message. A malicious peer could +specify an invalid size that exceeds the amount of available memory. +Replace call to `g_malloc()` with call to `g_try_malloc()`. If the memory could +not be allocated the function returns instead of causing the application to --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/hugo/content/about/security/advisories/independent-20041019-02.md Sat Jan 18 10:32:21 2020 -0600
@@ -0,0 +1,25 @@
+title: independent-20041019-02 +date: 2004-10-19T00:00:00.000Z +summary: MSN SLP buffer overflow +Buffer overflow. `memcpy` was used without checking the size of the buffer +before copying to it. Additionally, a logic flaw was causing the wrong buffer +to be used as the destination for the copy under certain circumstances. +Correct the logic to select the correct buffer, and add bounds checking to +prevent malformed messages causing a buffer overflow. Correct the logic to +select the correct buffer, and add bounds checking to prevent malformed +messages causing a buffer overflow. --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/hugo/layouts/security/advisories.html Sat Jan 18 10:32:21 2020 -0600
@@ -0,0 +1,19 @@
+{{ partial "header.html" . }} +{{- range .Pages.GroupByDate "2006-01-02" -}} + <h4><a href="{{ .Permalink }}">{{ .Summary }}</a></h4> + {{- if .Param "cveNumber" }}<li><a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name={{ .Param "cveNumber" | upper }}">{{ .Param "cveNumber" | upper }}</a></li>{{ end -}} + {{- if .Param "talosReportId" }}<li><a href="https://talosintelligence.com/vulnerability_reports/{{ .Param "talosReportId" | upper }}">{{ .Param "talosReportId" | upper }}</a></li>{{ end -}} +{{ partial "footline.html" . }} +{{ partial "footer.html" . }} --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/hugo/layouts/security/cve.html Sat Jan 18 10:32:21 2020 -0600
@@ -0,0 +1,64 @@
+{{ partial "header.html" . }} +{{- if and (eq (trim (.Param "cveNumber") " ") "") (eq (trim (.Param "talosReportId") " ") "") -}} + <p><em><b>NOTE:</b></em> This issue was not reported to a security reporting body.</p> + <td>{{ .Param "summary" }} </td> + <td>{{ .Date.Format "2006-01-02" }}</td> +{{- if .Param "cveNumber" -}} + <td><a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name={{ .Param "cveNumber" | upper }}">{{ .Param "cveNumber" | upper }}</a></td> +{{- if .Param "talosReportId" -}} + <td>Talos Report ID</td> + <td><a href="https://talosintelligence.com/vulnerability_reports/{{ .Param "talosReportId" }}">{{ .Param "talosReportId" | upper }}</a></td> + <td>{{ .Param "discoveredBy" }}</td> +{{- if .Param "fixedInRevision" -}} + <td>Fixed In Revision</td> + <td>{{ .Param "fixedInRevision" }}</td> + <td>Fixed In Release</td> + <td>{{ .Param "fixedInRelease" }}</td> +{{- with .PrevInSection -}} + <a href="{{ .Permalink }}">Previous<br/>{{ .Param "summary" }}</a> +{{- with .NextInSection -}} + <a href="{{ .Permalink }}">Next<br/>{{ .Param "summary" }}</a> +{{ partial "footline.html" . }} +{{ partial "footer.html" . }} --- a/hugo/static/css/custom.css Thu Jan 16 22:38:56 2020 -0600
+++ b/hugo/static/css/custom.css Sat Jan 18 10:32:21 2020 -0600
@@ -176,6 +176,22 @@
padding: 0.25rem !important;
/*****************************************************************************
*****************************************************************************/
